html2text waży tylko 0,2 MiB i instaluje jeden pakiet. Ma też licencję GPL-3.0.

html2text instaluje jeden pakiet o rozmiarze 0,2 MiB — to dziewięć razy mniej niż najbliższa alternatywa w Pythonie i czterdzieści razy mniej niż odpowiednik w Node. Narzędzie przeszło wszystkie cztery strony w zestawie testowym konwersji i zachowało wszystkie 16 zarejestrowanych probe’ów treści. Te probe’y sprawdzają, czy wybrane fragmenty tekstu z body przetrwają konwersję; nie oceniają hierarchii, zagnieżdżenia list, docelowych linków, powtarzających się treści ani pełnej zgodności tabel.

Dodatkowo projekt jest objęty licencją GPL-3.0-or-later, a to jedyna cecha w tym porównaniu, której nie pokaże żaden benchmark — i która może całkowicie wykluczyć bibliotekę z użycia.

Czym jest html2text

html2text to biblioteka Pythona, która zamienia HTML na tekst w stylu Markdown. Jej historia sięga oryginalnego projektu Aarona Swartza, a aktualnie utrzymywana linia ma wersję 2025.4.15 — wydanie datowane na kwiecień 2025, z 2 168 gwiazdkami na GitHubie, 95 otwartymi zgłoszeniami i ostatnim push’em w październiku 2025.

Oficjalne źródło: oficjalne repozytorium html2text.

import html2text
h = html2text.HTML2Text()
h.body_width = 0          # patrz niżej; domyślne ustawienie potrafi zaskoczyć
md = h.handle(html)

pip install html2text pobiera 1 pakiet i 0,2 MiB, a zimny import trwa 0,077 s. Zero zależności. W obrazie kontenera albo warstwie Lambda to bardzo realna różnica względem 1,8 MiB w markdownify i 8,8 MiB w turndown.

Domyślne ustawienie, które zmienia każdy wynik

body_width ma domyślną wartość 78. html2text zawija każdą linię wyjścia do 78 znaków, chyba że wyłączysz to ręcznie.

To sensowne ustawienie dla biblioteki, której pierwotnym zadaniem było tworzenie czytelnego tekstu dla terminali i poczty. To jednak zły wybór, jeśli wynik trafia do modelu albo do diff’a — w takich przypadkach wstawione znaki nowej linii zmieniają tokenizację, rozbijają długie linki i sprawiają, że porównywanie wyników traci sens.

Dla wszystkiego poniżej ustawiłem body_width = 0 i zaznaczam to otwarcie: przy włączonym zawijaniu każda liczba znaków i tokenów w tym artykule byłaby inna. Jeśli samodzielnie benchmarkujesz konwertery, to właśnie to ustawienie potrafi po cichu sprawić, że wyniki staną się nieporównywalne.

Jak wyglądał pomiar

Uruchomiłem html2text na nazwanym, czterostronicowym zestawie konwersji używanym też w porównaniu markitdown, z wcześniej zarejestrowanymi probe’ami — czyli wybranymi stringami z body, które muszą przetrwać, oraz tekstami pomocniczymi, których obecność pokazuje, że przeszła też otoczka strony. Te same cztery pliki, te same probe’y, jeden wspólny scorer dla wszystkich czterech konwerterów. Przeżycie probe’ów mierzy obecność zarejestrowanych stringów, a nie poprawność strukturalną; dlatego kolumny z tabelami i linkami liczone są osobno.

fourway-scores.json. Cztery fixture’y, tokeny liczone przy użyciu o200k_base.

Najmniejszy wynik wyjściowy z całej czwórki: 76 452 znaki, a pod względem tokenów praktycznie remis z markdownify i markitdown — 21 176 wobec 21 062 i 21 336, czyli różnica 1,3%, której nie nazwałbym istotną.

32 wiersze tabel wobec 36 w markdownify i markitdown w czterostronicowym zestawie. Brakujące cztery wiersze pojawiają się na nieregularnym fixture’ze z Wikipedii, a nie w różnicy formatowania zewnętrznych pionowych kresek opisanej niżej.

Najmniej linków: 545, wobec 598–611 u pozostałych. Warto sprawdzić to na własnych stronach, jeśli zachowanie linków ma znaczenie — to jedyna kolumna, w której html2text wyraźnie odstaje od grupy.

Tabel, których nie widział mój regex

Warto o tym wspomnieć, bo prawie opublikowałem błędny wniosek.

Mój pierwszy licznik wierszy tabel wymagał pionowych kresek na początku i końcu — ^\|.*\|$. Przy takim założeniu html2text zdobyłby 1 wiersz tabeli na pięć plików: cztery strony z zestawu konwersji oraz osobny syntetyczny fixture złożonej tabeli. Taki licznik mierzył jednak jeden styl Markdowna, a nie tabelę jako taką.

A jednak to robi. Wypisuje je tak:

Team Name  |  Year  |  Wins  |  Losses  |  Win %
---|---|---|---|---
Boston Bruins  |  1990  |  44  |  24  |  0.55

Bez zewnętrznych pionowych kresek. To standardowa składnia tabel pipe-table, ale harness nie weryfikował jej w różnych rendererach Markdown. Dla regexu oczekującego stylu z outer pipes jest to niewidoczne. Po przerobieniu licznika tak, by szukał ciągów linii zawierających kreski pionowe oraz wiersza separatora w środku, wynik html2text wzrósł z 1 wiersza do 32 w czterostronicowym zestawie i 91 we wszystkich pięciu plikach.

Wniosek nie brzmi więc: html2text nie obsługuje tabel. Wniosek brzmi: dwa z tych czterech konwerterów wypisują zewnętrzne pionowe kreski, a jeden nie — i to ma znaczenie, jeśli potem przetwarzasz Markdown własnymi regexami. To naprawdę ważna rzecz i całkiem by mi umknęła, gdybym zaufał pierwszemu wynikowi.

Co usuwa i gdzie traci wiersze

Dwa spostrzeżenia, które ciągną w przeciwnych kierunkach.

Usuwa <script> i <style>. Licząc znaczniki występujące wyłącznie wewnątrz tych elementów, html2text w całym zestawie zwraca zero markerów skryptu i zero markerów stylów. turndown zwraca 10 i 84 — na fixture’ze z Wikipedii, gdzie osiem linii wbudowanej konfiguracji JavaScript i CSS MediaWiki daje razem 14 644 znaki (script-style-stripping.json). W przypadku wyjścia przeznaczonego dla modelu była to największa zaobserwowana ilość zbędnego tekstu na tym fixture’ze. Nie liczono kosztów downstream.

Gubi wiersze tabel na trudnej stronie. Czterostronicowy zestaw po zsumowaniu wygląda tak:

Osobny syntetyczny fixture złożonej tabeli dodaje 59 wierszy html2text i 62 wiersze markdownify, co daje łącznie 91 i 98 we wszystkich pięciu plikach. Nie wchodzi to do głównego porównania czterostronicowego. Na czystej tabeli hokejowej oba narzędzia zgadzają się idealnie. Na Wikipedii, gdzie tabele są zagnieżdżone i nieregularne, html2text zwraca pięć wierszy, a markdownify dziewięć.

Wzorzec jest więc taki: proste tabele — identycznie; kłopotliwe tabele — html2text zachowuje mniej. Jeśli Twoje strony zawierają tabele podobne do tych z Wikipedii, sprawdź to przed wdrożeniem. Jeśli przypominają raczej tabelę ze strony ze statystykami, oba narzędzia są na tym polu wymienne.

Licencja

Oficjalne źródło: html2text w PyPI.

Potwierdzone w trzech miejscach: w metadanych PyPI, w repozytorium GitHub oraz w pliku METADATA z zainstalowanego pakietu, gdzie widnieje License-Expression: GPL-3.0-or-later.

Co to oznacza w praktyce, zależy od tego, jak oprogramowanie jest integrowane, przekazywane i dystrybuowane. Użycie wewnętrzne albo tylko sieciowe to zwykle inny scenariusz GPL niż dostarczanie oprogramowania, które zawiera ten pakiet lub jest z nim łączone, ale ten artykuł nie jest analizą prawną. Zespoły, które dystrybuują software, powinny poprosić prawnika o ocenę konkretnego modelu integracji i dystrybucji.

Najbardziej kłopotliwa jest tu korelacja. Biblioteka o najmniejszym śladzie, którą wybrałbyś właśnie po to, by utrzymywać mały artefakt dystrybucyjny, ma licencję, która najmocniej ogranicza dystrybucję. Obie alternatywy mają MIT.

Nie jestem prawnikiem i to nie jest porada — po prostu fakt, oparty na źródłach, bo to najważniejsza cecha i zarazem ta, która najrzadziej trafia do tabel porównawczych.

Utrzymanie

Ostatnie wydanie 2025.4.15, ostatni push do repozytorium w październiku 2025 — mniej więcej dziesięć miesięcy przed testem, z 41 wydaniami za sobą. requires_python >= 3.9, a pakiet zainstalował się i działał bez problemu na Pythonie 3.14.2.

To spokojniejszy rytm niż markdownify (ostatnie wydanie sześć tygodni przed testem) i turndown (cztery miesiące), ale wyraźnie aktywniejszy niż brak aktywności. Dla biblioteki, która zamienia HTML na tekst — czyli rozwiązuje problem, który nie zmienia się zbyt szybko — dziesięciomiesięczna przerwa wygląda raczej na stabilność niż porzucenie. 95 otwartych zgłoszeń to większa czerwona flaga i warto je przejrzeć pod kątem własnego przypadku użycia przed wdrożeniem.

Pamięć i wpływ uszkodzonego HTML-a

Dwa pytania operacyjne są tu mierzone osobno.

Szerszy kontekst testu obciążeniowego znajduje się w porównaniu pamięci i niepoprawnego HTML-a dla dziesięciu bibliotek.

Szczytowe użycie pamięci rezydentnej, mierzone przez /usr/bin/time -l, po jednym świeżym procesie na komórkę — próg importu to koszt samej biblioteki po załadowaniu i bezczynności, a piki obejmują już dokument.

memory-results.json. Bazowe wyniki Pythona i Node nie są ze sobą bezpośrednio porównywalne; interpreter jest w obu przypadkach częścią wyniku.

html2text jest tutaj najlżejszym wpisem w obu mierzonych wymiarach. Jego próg importu 18,7 MiB i szczyt 71,2 MiB na fixture’ze 10 MB dają przyrostowy RSS 52,5 MiB: (71,2 - 18,7) / 10 = 5,25× rozmiaru fixture’a. Porównaj to z wartościami bezwzględnymi i przyrostowymi w tabeli, pamiętając o zastrzeżeniu dotyczącym porównywalności baz Python/Node.

Uszkodzony HTML. Dwanaście dokumentów, z których każdy psuje dokładnie jedną rzecz — niezamknięte tagi, źle zagnieżdżone elementy inline, atrybuty bez cudzysłowów i spacjami, samotne zamknięcia, brak <html> w ogóle, zduplikowane atrybuty, dokument ucięty w połowie taga, błędne encje, niezamknięty <script>, kłamliwa deklaracja charset, komentarz zawierający markup oraz 600 poziomów zagnieżdżenia — plus dwie poprawne próbki kontrolne o dopasowanych rozmiarach, bo stwierdzenie „nic nie zwróciło” mówi coś o uszkodzeniu tylko wtedy, gdy biblioteka milczy także na czystym dokumencie o tej samej wielkości.

html2text rzucił wyjątek na 0 z 14 przypadków i nie zwrócił nic na 0, odzyskując 33/33 znaczniki kontrolne w uszkodzonych fixture’ach (malformed-results.json). Jeden fixture jest z tego liczenia wyłączony: zgodnie z HTML5 wszystko po niezamkniętym <script> jest treścią skryptu, więc utrata tego fragmentu jest poprawna, a jego odzyskanie byłoby odchyleniem.

Plusy i minusy

Na plus. Jeden pakiet, 0,2 MiB, zero zależności — zdecydowanie najmniej w całym porównaniu. Najmniejszy wynik wyjściowy z czwórki i praktycznie remis tokenowy z markdownify i markitdown. Generuje rozpoznawalną składnię tabel pipe-table. Działa na Pythonie 3.14. Długa, stabilna linia rozwoju.

Na minus. GPL-3.0-or-later, czego pozostałe opcje nie mają. Domyślne body_width=78, które zawija wynik i zmienia pomiary oraz diffy, jeśli nie wyłączysz tego ręcznie. Najmniej zachowanych linków (545 wobec 598–611). Tabele mają styl bez zewnętrznych pionowych kresek, więc psują proste regexy downstream. 95 otwartych zgłoszeń i wolniejszy rytm wydań niż markdownify.

Kto powinien używać, a kto nie

Użyj html2text, jeśli budżet zależności jest naprawdę ciasny, a planowana integracja i model dystrybucji przeszły już analizę licencyjną. Jeden pakiet i zero zależności to realna przewaga operacyjna: mniejsza powierzchnia do audytu i wdrożenia.

Ustaw body_width = 0 w pierwszej linii, chyba że celowo chcesz zawijany tekst płaski.

Pomiń to narzędzie, jeśli dystrybuujesz software i copyleft stanowi problem — markdownify ma MIT, w tym teście ma podobny rozmiar wyjścia i liczbę tokenów, zachowuje więcej linków i więcej nieregularnych wierszy tabel, a zajmuje tylko 1,6 MiB więcej. Pomiń je także, jeśli zachowanie linków jest dla Ciebie kluczowe, bo html2text zachował ich najmniej. I pomiń, jeśli Twoje narzędzia downstream zakładają zewnętrzne pionowe kreski w wierszach tabel.

Gdzie pasuje zarządzane API

html2text konwertuje HTML, który już masz. Nie pobiera stron, nie renderuje JavaScriptu i nie radzi sobie z warstwą anty-bot — żadnego z tych zadań nie wykonuje też żaden z czterech konwerterów, a na wielu realnych celach właśnie to jest trudniejsza połowa pracy.

Dla tych samych fixture’ów we wszystkich pięciu konwerterach zobacz pięciostronne porównanie HTML-to-Markdown.

Hostowana usługa pobierania/renderowania/ekstrakcji, w tym nasz własny Thunderbit, działa na innym poziomie. Thunderbit nie był tutaj benchmarkowany. Istotna granica przebiega między konwersją dostarczonego HTML-a a usługą, która sama pobiera i przetwarza URL; ten artykuł nie zawiera porównania jakości, opóźnień ani kosztów w tym samym metrycznym ujęciu.

Uczciwe ujęcie jest takie: jeśli masz HTML, chcesz Markdown i GPL nie jest problemem dla sposobu dystrybucji, html2text jest darmowy i zaskakująco mały. Jeśli pobierasz strony albo potrzebujesz raczej wierszy niż narracji, to już zupełnie inny zakup.

Szerszy przegląd rynku znajdziesz w naszym zestawieniu API do web scrapingu, a pillar o open-source scraperach omawia rozwiązania self-hosted. Konwersja HTML do Markdown w Pythonie to praktyczny przewodnik.

Wypróbuj Thunderbit do ekstrakcji danych z sieci

Czy warto używać html2text?

To mocny kandydat, gdy liczy się mały footprint, celowo wyłączasz zawijanie i model dystrybucji przechodzi analizę licencyjną.

W czterostronicowym zestawie liczba tokenów była w granicach 1,3% od markdownify i markitdown. Nie oznacza to jednak pełnej równoważności jakości: html2text zachował mniej linków i mniej wierszy nieregularnej tabeli z Wikipedii. Dwie rzeczy operacyjne wymagają natychmiastowej uwagi: body_width = 0 oraz styl tabel bez zewnętrznych pionowych kresek.

Jeśli analiza GPL wyklucza tę bibliotekę, markdownify ma MIT, w tym teście dawał podobny rozmiar wyjścia i podobną liczbę tokenów, zachował więcej linków oraz więcej wierszy z nieregularnych tabel, a w tym środowisku zajmował o 1,6 MiB więcej miejsca na dysku.

Wypróbuj Thunderbit do ekstrakcji danych z sieci Get Started Free

FAQ

Czy html2text konwertuje tabele? Tak. Mój pierwszy licznik powiedział, że wygenerował jeden wiersz tabeli na pięć plików, ale to był błąd — licznik wymagał pionowych kresek na początku i końcu, podczas gdy html2text wypisuje Team Name | Year | Wins bez nich. To nadal standardowy Markdown dla tabel pipe-table, choć ten harness nie sprawdzał zgodności między rendererami. Po poprawieniu licznika html2text wygenerował 32 wiersze wobec 36 w markdownify w czterostronicowym zestawie oraz 91 wobec 98 po dodaniu osobnego fixture’a złożonej tabeli.

Co robi body_width i po co go zmieniać? Domyślnie zawija wynik co 78 znaków, co ma sens dla tekstu czytelnego w terminalu, ale słabo sprawdza się wszędzie indziej. Zawijanie wstawia nowe linie w środku zdań, rozbija długie URL-e i zmienia tokenizację. Wszystkie liczby w tej recenzji używają body_width = 0; przy domyślnej wartości byłyby inne.

Czy licencja GPL naprawdę ogranicza użycie? To zależy od dokładnego modelu integracji i dystrybucji. Użycie wewnętrzne, tylko sieciowe i dostarczanie oprogramowania to różne scenariusze oceny, ale ten artykuł nie przesądza o ich skutkach prawnych. Zespoły wypuszczające software powinny skonsultować warunki GPL-3.0-or-later z prawnikiem; markdownify i turndown mają MIT. Ekspresja licencyjna html2text została potwierdzona w metadanych PyPI, w GitHubie i w pliku METADATA z zainstalowanego pakietu.

Czy wydanie z kwietnia 2025 to problem? Samo w sobie raczej nie. Konwersja HTML do tekstu to stabilny problem, biblioteka działała poprawnie na Pythonie 3.14.2, a za nią stoi 41 wcześniejszych wydań. 95 otwartych zgłoszeń to liczba, którą rzeczywiście warto sprawdzić — przejrzyj je pod kątem tego, czy coś przypomina Twój przypadek użycia, bo ciche repozytorium oznacza często, że to Ty będziesz musiał je poprawiać.

Czego tu nie testowano? Cztery fixture’y konwersji i jeden osobny fixture złożonej tabeli to nadal mały zestaw. Test obejmował jednak dwanaście syntetycznych dokumentów z błędnym HTML-em oraz dwie próbki kontrolne: html2text rzucił wyjątek w 0/14 przypadków, nie zwrócił pustego wyniku w 0/14 i odzyskał wszystkie 33 oceniane znaczniki kontrolne. Nie obejmował uszkodzonych stron z realnego świata, szerszych wzorców błędów HTML, zagnieżdżonych list, list definicyjnych, przypisów ani matematyki. Cała powierzchnia opcji — ignore_links, ignore_images, unicode_snob, single_line_break i pozostałe — pozostała na ustawieniach domyślnych poza body_width. Różnica w zachowaniu linków została zauważona, ale nie zdiagnozowana, a round-tripping Markdown nie był testowany.