html2text is 0,2 MiB en één pakket. En het heeft ook GPL-3.0.

html2text installeert één pakket en neemt 0,2 MiB in beslag — negen keer kleiner dan het dichtstbijzijnde Python-alternatief en veertig keer kleiner dan de Node-optie. Het doorliep alle vier pagina’s in de conversiesuite en behield alle 16 geregistreerde body-probes. Die probes controleren of geselecteerde body-strings behouden blijven; ze beoordelen geen hiërarchie, nesting van lijsten, linkdoelen, herhaalde content of volledige tabelgetrouwheid.

Het is bovendien gelicentieerd onder GPL-3.0-or-later, en dat is in deze vergelijking juist de eigenschap die in geen enkele benchmark terugkomt, maar wél een bibliotheek volledig kan uitsluiten.

Wat html2text is

html2text is een Python-bibliotheek die HTML omzet naar Markdown-achtige platte tekst. De lijn gaat terug tot het oorspronkelijke werk van Aaron Swartz, en de huidige onderhouden tak staat op 2025.4.15 — een release met datumversie uit april 2025, met 2.168 GitHub-sterren, 95 open issues en een laatste push in oktober 2025.

Officiële referentie: html2text's officiële repository.

import html2text
h = html2text.HTML2Text()
h.body_width = 0          # zie hieronder; de standaardinstelling zal je verrassen
md = h.handle(html)

pip install html2text haalt 1 pakket en 0,2 MiB binnen, en doet een cold import in 0,077 s. Geen afhankelijkheden. In een containerimage of Lambda-layer is dat een duidelijk verschil met markdownify’s 1,8 MiB en turndown’s 8,8 MiB.

De standaardinstelling die elk getal verandert

body_width staat standaard op 78. html2text hard-wrappet alle outputregels op 78 tekens, tenzij je dit uitzet.

Dat is een prima standaard voor een bibliotheek waarvan de oorspronkelijke taak was om leesbare platte tekst te maken voor terminals en e-mail. Het is de verkeerde standaard voor alles wat naar een model of een diff gaat, waar extra regeleinden tokenisatie veranderen, lange links over meerdere regels laten lopen en vergelijking van output zinloos maken.

Ik heb hieronder overal body_width = 0 ingesteld, en ik noem dat expliciet in plaats van het te verstoppen: mét wrapping aan zouden alle teken- en tokenaantallen in dit artikel anders zijn. Als je zelf converters benchmarkt, is dit de instelling die je cijfers stilletjes onvergelijkbaar maakt.

De meting

Ik heb html2text uitgevoerd op een vierpagina-testset met naam, dezelfde set die ook is gebruikt voor de markitdown-vergelijking, met vooraf geregistreerde probe-strings — geselecteerde body-strings die moeten overleven, plus boilerplate-strings waarvan de aanwezigheid laat zien dat de paginacharacteristieken zijn meegekomen. Dezelfde vier bestanden, dezelfde probes, één scorer voor alle vier converters. Probe-overleving meet de aanwezigheid van geregistreerde strings, niet structurele correctheid; de tabel- en linkkolommen staan juist daarom apart.

fourway-scores.json. Vier fixtures, tokens geteld met o200k_base.

De kleinste output van de vier met 76.452 tekens, en in tokens praktisch gelijk aan markdownify en markitdown — 21.176 tegenover 21.062 en 21.336, een spreiding van 1,3% die ik geen verschil zou noemen.

32 tabelrijen tegenover markdownify’s en markitdown’s 36 in de vierpagina-testset. Het verschil van vier rijen zit in de onregelmatige Wikipedia-fixture, niet in het buitenste-pipe-verschil dat verderop wordt besproken.

Het minste aantal links: 545, tegenover 598 tot 611 bij de rest. Zeker vergelijken met je eigen pagina’s als linkbehoud belangrijk is — dit is de ene kolom waarin html2text duidelijk onder de groep zit in plaats van erbinnen.

De tabellen die mijn regex niet zag

Dit is het waard om te vertellen, omdat ik bijna de verkeerde conclusie hierover had gepubliceerd.

Mijn eerste teller voor tabelrijen vereiste een leidende en afsluitende pipe — ^\|.*\|$. Volgens die regel scoorde html2text 1 tabelrij over vijf bestanden: de vierpagina-testset plus een aparte synthetische fixture met een complexe tabel. Die teller mat één Markdown-stijl, geen tabellen.

Het doet dat wel. Het zet ze er ongeveer zo uit:

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

Geen buitenste pipes. Dit is normale pipe-table-syntax, maar het testkader valideerde dit niet over Markdown-renderers heen. Daardoor bleef het onzichtbaar voor een regex die de stijl met buitenste pipes verwacht. Na herschrijven van de teller om te zoeken naar een reeks regels met pipes plus een scheidingsregel ertussen, ging html2text van 1 rij naar 32 in de vierpagina-testset en 91 over alle vijf bestanden.

De conclusie is dus niet dat html2text geen tabellen heeft. De conclusie is dat twee van deze vier converters outer pipes gebruiken en één niet, en dat is relevant als je de Markdown daarna met eigen patroonherkenning verwerkt. Dat is echt nuttige informatie — en die had ik volledig gemist als ik mijn eerste getal had vertrouwd.

Wat het verwijdert, en waar het rijen verliest

Twee bevindingen die in tegengestelde richting wijzen.

Het verwijdert <script> en <style>. Geteld via markers die alleen in die elementen voorkomen, bevat html2text’s output over de fixtures nul script-markers en nul style-markers. turndown’s output bevat 10 en 84 — op de Wikipedia-fixture gaat het om acht regels met inline JavaScript-configuratie van MediaWiki en CSS ter waarde van 14.644 tekens (script-style-stripping.json). Voor modelgerichte output was dit de grootste waargenomen bron van vermijdbare tekst op die fixture. Er is geen downstream-kostenmodel gemeten.

Het verliest tabelrijen op de lastige pagina. De vierpagina-testset komt als volgt uit:

De aparte synthetische fixture met complexe tabel voegt 59 html2text-rijen en 62 markdownify-rijen toe, waarmee de totaalscore over vijf bestanden uitkomt op 91 en 98. Die fixture hoort niet bij de hoofdvergelijking van vier pagina’s. Op de nette hockeytabel zijn de tools gelijkwaardig. Op Wikipedia, waar de tabellen genest en onregelmatig zijn, geeft html2text vijf rijen weer waar markdownify er negen geeft.

Het patroon is dus: eenvoudige tabellen, identiek; lastige tabellen, html2text houdt minder over. Als je pagina’s het soort tabellen hebben dat Wikipedia heeft, test dat dan vóór je beslist. Als ze lijken op een statistiekpagina, zijn de twee op dit punt uitwisselbaar.

De licentie

Officiële referentie: html2text op PyPI.

Bevestigd op drie plekken: de PyPI-metadata, de GitHub-repository en het eigen METADATA-bestand van het geïnstalleerde pakket, waar License-Expression: GPL-3.0-or-later staat.

Wat dat betekent, hangt af van hoe de software wordt geïntegreerd, verspreid en gedistribueerd. Intern gebruik of alleen via het netwerk is doorgaans een ander GPL-scenario dan software uitbrengen die het pakket bevat of ermee combineert, maar dit artikel is geen juridisch advies. Teams die software distribueren, moeten hun concrete integratie- en distributiemodel door counsel laten beoordelen.

Het lastige is de correlatie. De bibliotheek met de kleinste footprint — precies degene die je zou kiezen omdat je een distribueerbaar artefact zo klein mogelijk wilt houden — is juist degene met de licentie die distributie het meest beperkt. Beide alternatieven zijn MIT.

Ik ben geen jurist en dit is geen advies — alleen het feit, met bronvermelding, omdat dit de eigenschap is die het meest waarschijnlijk telt en het minst waarschijnlijk in een vergelijkingstabel staat.

Onderhoud

Laatste release 2025.4.15, laatste push naar de repository in oktober 2025 — ongeveer tien maanden vóór de test, met 41 releases daarvoor. requires_python >= 3.9, en het installeerde en draaide probleemloos op Python 3.14.2.

Dat is rustiger dan markdownify (laatste release zes weken vóór de test) en turndown (vier maanden), en aanzienlijk actiever dan helemaal niets. Voor een bibliotheek die HTML naar tekst omzet — een probleem dat niet snel verandert — leest een gat van tien maanden als stabiel, niet als verlaten. Vijfennegentig open issues is de grotere waarschuwing, en die zou ik bekijken op alles wat op jouw use case lijkt voordat je beslist.

Geheugen, en wat kapotte HTML daarmee doet

Twee operationele vragen worden hier apart gemeten.

De bredere stress-testcontext staat in de vergelijking van tien libraries op geheugen en foutieve HTML.

Piek resident memory, via /usr/bin/time -l, telkens één vers proces per cel — de import floor is wat de library kost als hij geladen en idle is, de pieken bevatten het document.

memory-results.json. Python- en Node-baselines zijn onderling niet direct vergelijkbaar; de interpreter zit in beide.

html2text is hier de lichtste entry op beide gemeten assen. De import floor van 18,7 MiB en de piek van 71,2 MiB op de 10 MiB-fixture geven een incrementele RSS van 52,5 MiB: (71.2 - 18.7) / 10 = 5.25× de fixturegrootte. Vergelijk dat met de absolute en incrementele regels in de tabel, met de genoemde Python/Node-baseline-opmerking in het achterhoofd.

Foutieve HTML. Twaalf documenten waarin telkens precies één ding stuk is — ongeopende tags, verkeerd geneste inline-elementen, attributen zonder aanhalingstekens met spaties, losse afsluiters, helemaal geen <html>, dubbele attributen, een document dat midden in een tag afbreekt, slechte entities, een onafgesloten <script>, een leugenachtige charset-declaratie, een comment met markup en 600 niveaus van nesting — plus twee goed gevormde controles met vergelijkbare grootte, want "het gaf niets terug" zegt alleen iets over malformedness als de library op een schoon document van dezelfde grootte ook stil blijft.

html2text gaf een fout op 0 van 14 en leverde op 0 niets terug, en herstelde 33/33 sentinels over de kapotte fixtures (malformed-results.json). Eén fixture telt niet mee in die telling: volgens HTML5 is alles ná een onafgesloten <script> script-content, dus dat kwijt raken is daar correct en het terughalen juist een afwijking.

Voor- en nadelen

In het voordeel. Eén pakket, 0,2 MiB, geen afhankelijkheden — veruit de kleinste in de vergelijking. Kleinste output van de vier en qua tokens praktisch gelijk aan markdownify en markitdown. Produceert herkenbare pipe-table-syntax. Werkt op Python 3.14. Lange, stabiele geschiedenis.

Tegen. GPL-3.0-or-later, en dat zijn de alternatieven niet. body_width=78 standaard, waardoor output hard wordt afgebroken en metingen of diffs veranderen tenzij je het uitzet. Het minste aantal behouden links (545 tegenover 598–611). Tabellen gebruiken de stijl zonder outer pipes, wat naïeve downstream-regex breekt. Vijfennegentig open issues en een rustigere releasecadans dan markdownify.

Wie het wel en niet zou moeten gebruiken

Gebruik html2text als het afhankelijkheidsbudget echt krap is en het beoogde integratie- en distributiemodel al juridisch is beoordeeld. Eén pakket met nul afhankelijkheden is een echt operationeel voordeel: een kleinere afhankelijkheidsmatrix om te auditen en uit te rollen.

Zet body_width = 0 op de eerste regel, tenzij je specifiek om gewrapte platte tekst vraagt.

Sla het over als je software distribueert en copyleft een probleem is — markdownify is MIT, evenaart het op tokens en komt voor 1,6 MiB extra opslag in deze setup overeen met markitdown op tabellen. Sla het ook over als linkbehoud voor jou belangrijk is, want daarin hield het de minste over. En sla het over als je downstream-tooling uitgaat van outer pipes in tabelrijen.

Waar een managed API past

html2text zet HTML om die je al hebt. Het haalt niets op, rendert geen JavaScript en handelt geen anti-botlaag af — geen van de vier converters doet dat, en op veel echte doelpagina’s is dat juist de moeilijkere helft.

Voor dezelfde fixtures over alle vijf converters zie de vijfweg-vergelijking van HTML naar Markdown.

Een gehoste fetch/render/extract-service, inclusief onze eigen Thunderbit, werkt op een andere laag. Thunderbit is hier niet gebenchmarkt. De relevante grens is geconverteerde HTML versus een dienst die een URL ophaalt en verwerkt; dit artikel geeft geen vergelijking van kwaliteit, latency of kosten op dezelfde meetlat.

De eerlijke samenvatting: als je de HTML al hebt, Markdown wilt, en GPL voor jouw distributiemodel geen probleem is, dan is html2text gratis en opvallend klein. Als je pagina’s moet ophalen, of liever rijen dan proza wilt, dan koop je iets anders.

Voor het bredere veld behandelt onze overzichtspagina met webscraping-API’s gehoste opties en de open-source scraper-pijler de zelf gehoste varianten. HTML naar Markdown converteren in Python is de praktische handleiding.

Probeer Thunderbit voor webdata-extractie

Moet je html2text gebruiken?

Het is een sterke kandidaat als footprint belangrijk is, wrapping bewust uit staat en het distributiemodel door de licentiecheck komt.

De tokenaantallen lagen in de vierpagina-testset binnen 1,3% van markdownify en markitdown. Dat betekent niet dat de totale kwaliteit gelijk is: html2text behield minder links en minder rijen op de onregelmatige Wikipedia-fixture. Twee operationele details zijn meteen relevant: body_width = 0 en de tabelstijl zonder outer pipes.

Als GPL-review het uitsluit, is markdownify MIT, had hier een vergelijkbare outputgrootte en tokenaantallen, behield meer links en meer onregelmatige tabelrijen, en gebruikte in deze omgeving 1,6 MiB extra opslag.

Probeer Thunderbit voor webdata-extractie Get Started Free

Veelgestelde vragen

Kan html2text tabellen omzetten? Ja. Mijn eerste teller zei dat het over vijf bestanden slechts één tabelrij produceerde, en die teller was fout — die vereiste een leidende en afsluitende pipe, terwijl html2text Team Name | Year | Wins zonder die pipes uitspuugt. Dat is normale Markdown in pipe-table-stijl, al heeft dit testkader geen compatibiliteitstest over meerdere renderers gedaan. Met de gecorrigeerde teller produceerde html2text 32 rijen tegenover markdownify’s 36 in de vierpagina-testset, en 91 tegenover 98 wanneer de aparte complexe-tabel-fixture wordt meegerekend.

Wat doet body_width, en waarom zou je het aanpassen? Het hard-wrappet output standaard op 78 tekens, een logische keuze voor terminal-leesbare platte tekst en een slechte voor vrijwel alles anders. Wrapping voegt regeleinden midden in zinnen toe, breekt lange URL’s over meerdere regels en verandert tokenisatie. Alle cijfers in deze review gebruikten body_width = 0; met de standaardinstelling zouden ze allemaal anders zijn.

Is de GPL-licentie echt een beperking? Dat hangt af van het exacte integratie- en distributiemodel. Intern gebruik of alleen via het netwerk en het distribueren van software zijn verschillende scenario’s, maar dit artikel bepaalt niet de juridische uitkomst. Teams die software uitbrengen moeten de GPL-3.0-or-later-voorwaarden door counsel laten beoordelen; markdownify en turndown zijn MIT. De licentie-expressie van html2text is bevestigd in PyPI-metadata, GitHub en het METADATA-bestand van het geïnstalleerde pakket.

Is een release uit april 2025 een probleem? Waarschijnlijk niet, op zichzelf niet. HTML-naar-tekst-conversie is een stabiel probleem, de bibliotheek installeerde en draaide schoon op Python 3.14.2, en er zitten 41 releases achter. Vijfennegentig open issues zijn het getal dat ik echt zou checken — scan ze op alles wat op jouw input lijkt voordat je beslist, want een stille repository betekent vaak dat jij degene bent die het moet fixen.

Wat is hier niet getest? Vier conversie-fixtures en één aparte complexe-tabel-fixture zijn nog steeds een kleine set. De test omvatte wel twaalf synthetische malformed documenten plus twee controles: html2text gaf 0/14 fouten, gaf 0/14 lege output terug en herstelde alle 33 gescoorde sentinels. Getest werden niet: echt beschadigde webpagina’s, bredere malformed patronen, geneste lijsten, definitieslijsten, voetnoten of wiskunde. De volledige optieset — ignore_links, ignore_images, unicode_snob, single_line_break en de rest — bleef op de standaardinstellingen staan, behalve body_width. Het verschil in links is waargenomen maar niet verder geanalyseerd, en Markdown round-tripping is niet getest.