Kostenloser PDF-zu-HTML-Konverter

Extrahieren Sie Text aus PDF-Dokumenten und konvertieren Sie ihn in sauberes, semantisches HTML. Sofortige Vorschau, Code zum Herunterladen oder Kopieren.

Ihre Daten verlassen Ihr Gerät nie
PDF hier ablegen oder klicken zum Auswählen (max. 10 MB)

Verarbeitung läuft…

Über die PDF-zu-HTML-Konvertierung

Dieses Tool nutzt PDF.js, um Textinhalte aus PDF-Dateien zu extrahieren und sie als semantisches HTML wiederzugeben. Ideal, um Dokumente in ein webfreundliches Format zu konvertieren, Inhalte zu archivieren oder Text für die weitere Verarbeitung vorzubereiten.

Häufige Anwendungsfälle

Häufige Fragen

Welche PDF-Dateigrößen werden unterstützt?

Dieses Tool kann je nach Browser PDFs bis etwa 10 MB verarbeiten. Sehr große oder komplexe PDFs können länger benötigen.

Bleibt die Formatierung des PDFs erhalten?

Das Tool extrahiert den Textinhalt und gibt ihn als Absätze wieder. Komplexe Layouts, Bilder und Stile werden zu sauberem HTML vereinfacht.

Kann ich das HTML herunterladen?

Ja. Klicken Sie auf „HTML herunterladen", um den konvertierten Inhalt als .html-Datei zu speichern, die Sie in jedem Browser oder Editor öffnen können.

Eine kurze Geschichte von PDF, von PostScript zur portablen Seite

Das Portable Document Format war die Idee von John Warnock, dem Mitbegründer von Adobe Systems, der zuvor PostScript mitentwickelt hatte, die Seitenbeschreibungssprache, die ab 1985 mit dem Apple LaserWriter das Desktop-Publishing möglich machte. PostScript war außerordentlich leistungsfähig, aber es war eine Programmiersprache, kein Dokumentformat: Eine PostScript-Datei beschrieb, wie eine Seite zu rendern ist, wenn man sie einem Interpreter übergibt, doch sie war nicht wirklich dafür gedacht, gelesen, bearbeitet oder über Maschinen hinweg, denen die richtigen Schriften fehlten, einheitlich dargestellt zu werden.

1991 ließ Warnock ein internes Adobe-Memo zirkulieren, das als Camelot-Projekt bekannt wurde. Die Prämisse: Adobe sollte ein einziges Dateiformat schaffen, das jedes Dokument (einschließlich seiner Schriften, seines Layouts, seiner Vektorgrafiken und Bilder) erfassen und auf jedem Computer, auf jedem Betriebssystem identisch wiedergeben kann, unabhängig davon, welche Anwendung es ursprünglich erstellt hat. Als der Vorschlag ausgereift war, hatte das Projekt einen Produktnamen: Adobe Acrobat.

Acrobat 1.0 und PDF 1.0 wurden im November 1992 auf der Comdex Fall in Las Vegas vorgeführt und im Juni 1993 an Kunden ausgeliefert. Adobes entscheidende kommerzielle Weichenstellung kam 1994, als das Unternehmen begann, den Acrobat Reader kostenlos abzugeben, ein Schritt, der das widerspiegelte, was bei HTML-Browsern geschehen war, und eine Basis von Millionen Installationen schuf. Das Format durchlief mehrere Überarbeitungen: PDF 1.1 (1996, externe Links und Sicherheit), 1.2 (1996, AcroForms), 1.3 (2000, digitale Signaturen), 1.4 (2001, Transparenz), 1.5 (2003, Objektströme und JPEG 2000), 1.6 (2004, OpenType und 3D), 1.7 (2006). 2008 wurde PDF 1.7 als ISO 32000-1:2008 veröffentlicht; PDF 2.0 folgte als ISO 32000-2:2017, mit einer grundlegend überarbeiteten zweiten Ausgabe (ISO 32000-2:2020), die Errata einarbeitete und die aktuelle maßgebliche Referenz ist.

Neben der Hauptnorm gibt es mehrere spezialisierte PDF-Profile: PDF/A (ISO 19005-1:2005, mit -2 im Jahr 2011 und -3 im Jahr 2012) ist das Archivprofil, das Funktionen verbietet, die von externen Ressourcen oder künftiger Software abhängen (kein JavaScript, kein Audio, keine Verschlüsselung, Schriften müssen eingebettet sein); PDF/X ist das Druckvorstufenprofil der Druckindustrie; PDF/E ist das Engineering-Profil für technische Zeichnungen; PDF/UA (ISO 14289-1:2014) ist das Profil für universelle Barrierefreiheit, das eine logische Struktur und Auszeichnung erfordert, damit Screenreader Inhalte in Lesereihenfolge präsentieren können; PDF/VT ist das variable und transaktionale Profil, das im personalisierten Serienbrief verwendet wird.

Warum PDF-zu-HTML strukturell schwierig ist

Ein PDF ist auf seiner untersten Ebene eine Sammlung nummerierter Objekte (Dictionaries, Arrays, Strings, Zahlen, Namen und Binärströme), die mit einer Querverweistabelle am Ende angeordnet sind, die es einem Leseprogramm erlaubt, zu jedem Objekt zu springen, ohne die ganze Datei zu parsen. Die Objekte bilden einen Baum mit einer Wurzel in einem Catalog-Objekt, das auf einen Pages-Baum verweist, der Page-Objekte enthält. Jede Page verweist auf einen Content-Stream: die eigentlichen Anweisungen, die die Seite zeichnen.

Ein Content-Stream ist eine Folge kompakter Grafikoperatoren in einer kleinen Sprache, die mit PostScript verwandt, aber nicht Turing-vollständig ist. Für Text verwendet er Tf (Schrift und Größe setzen), Td (Textposition verschieben), Tm (Textmatrix setzen), Tj (einen String ausgeben), TJ (ein Array von Strings mit optionalen einzelnen Zeichenversätzen für Unterschneidung ausgeben) und ET (Text beenden). Der entscheidende Punkt ist, dass alles positionsbasiert ist. Ein Absatz Fließtext wird nicht als Absatz gespeichert. Er wird als Folge von Tj- oder TJ-Befehlen gespeichert, von denen jeder einen Glyphen oder einen kurzen Lauf von Glyphen an einer bestimmten x- und y-Koordinate auf der Seite zeichnet. Es gibt keinen Begriff von Satz, Absatz, Überschrift, Liste oder Spalte, nur die Frage, wo jedes Zeichen physisch sitzt.

HTML ist das Gegenteil: ein fließender Baum semantischer Elemente, bei dem das Layout in der Verantwortung des Renderers liegt und dasselbe HTML sich neu umbrechen kann, um auf ein Telefon, einen Desktop oder einen Screenreader zu passen. Ein PDF in HTML umzuwandeln erfordert daher das Rückentwickeln einer Struktur, die das PDF nie aufzeichnen musste. Ein Konverter muss die räumliche Verteilung des Textes auf jeder Seite betrachten und Folgendes ableiten:

Nichts davon wird gelöst, indem man den Content-Stream der Reihe nach liest, denn die Reihenfolge im Stream ist nicht unbedingt die Lesereihenfolge. Eine Layout-Engine, die das PDF erzeugt hat, mag Elemente in der für das Rendern effizientesten Reihenfolge gezeichnet haben, die von oben nach unten im Zickzack, nach Schrift oder nach Farbe verlaufen kann. Der Text eines einzelnen Absatzes kann im zugrunde liegenden Stream mit Text benachbarter Absätze verschachtelt sein. Deshalb erzeugen PDF-Extraktoren, die Strings einfach in Stream-Reihenfolge aneinanderhängen, für alles, was komplexer ist als ein einspaltiger Roman, eine verstümmelte Ausgabe.

Wenn das PDF ausgezeichnet (tagged) wurde, das heißt, wenn sein Autor neben dem visuellen Inhalt einen Strukturbaum aufgenommen hat, wird die Aufgabe weit einfacher. Ein ausgezeichnetes PDF enthält eine Hierarchie von Strukturelementen (P für Absatz, H1 bis H6 für Überschriften, L für Liste, LI für Listenelement, Table, TR, TD, Figure, Caption), die das semantische Vokabular von HTML widerspiegeln. PDF/UA schreibt die Auszeichnung für die Barrierefreiheit gerade deshalb vor, weil nicht ausgezeichnete PDFs für assistive Technik im Grunde undurchsichtig sind. In der Praxis ist die Mehrheit der PDFs in freier Wildbahn jedoch nicht ausgezeichnet oder vom Erstellungswerkzeug schlecht ausgezeichnet, sodass ein robuster Konverter selbst bei vorhandenen Tags auf die Layout-Analyse zurückgreifen muss.

Die wichtigsten Open-Source-Bibliotheken zum PDF-Rendering

PDF.js ist die von Mozilla geschriebene JavaScript-Bibliothek, ursprünglich im Juni 2011 als experimentelles Projekt unter der Leitung von Andreas Gal gestartet. Sie parst und rendert PDFs vollständig im Browser mithilfe von HTML5-Canvas und JavaScript, ohne dass ein natives Plugin erforderlich ist. PDF.js wurde ab Firefox 19 im März 2013 als Standard-PDF-Betrachter in Firefox integriert und ersetzte das Adobe-Reader-Plugin. Sie stellt eine JavaScript-API bereit, mit der eine Seite Textinhalte mit Positionsmetadaten extrahieren kann (jeder Textlauf kommt mit seiner x-, y-Koordinate, Breite, Höhe, seinem Schriftnamen und seiner Schriftgröße zurück). Dieses Tool basiert auf PDF.js.

Poppler ist eine C++-Bibliothek, abgespalten von xpdf, dem altehrwürdigen PDF-Betrachter, den Glyph and Cog seit Ende der 1990er-Jahre pflegt. Poppler treibt die PDF-Rendering-Funktionen von Linux-Desktop-Umgebungen (Evince in GNOME, Okular in KDE), die Kommandozeilen-Werkzeuge pdftotext und pdftohtml sowie viele serverseitige PDF-Verarbeitungs-Pipelines an. MuPDF von Artifex Software (derselben Firma, die Ghostscript pflegt) ist eine kleinere und schnellere C-Bibliothek für den eingebetteten Einsatz. PDFium ist die Engine, die in Google Chrome und Microsoft Edge für die eingebaute PDF-Anzeige steckt; sie ist eine Abspaltung des proprietären Foxit PDF SDK, das Google und Foxit im Mai 2015 gemeinsam quelloffen machten. qpdf ist eine C++-Bibliothek und ein Kommandozeilen-Werkzeug, das sich auf strukturelle Manipulation statt auf das Rendern konzentriert; es kann PDFs dekomprimieren, verschlüsseln, entschlüsseln, linearisieren und neu schreiben, ohne ihren visuellen Inhalt zu verändern.

Speziell für die Erzeugung von HTML-Ausgabe ist das wichtigste eigens dafür gebaute Projekt pdf2htmlEX, ursprünglich 2012 von Lu Wang geschrieben und jetzt von einer Community-Gruppe gepflegt. pdf2htmlEX verfolgt einen anderen Ansatz als die meisten Konverter: Statt zu versuchen, semantisches HTML zu rekonstruieren, gibt es das visuelle Layout des PDF so getreu wie möglich wieder, indem es für jeden Textlauf absolut positionierte div-Elemente ausgibt, die Originalschriften als WOFF-Dateien (Web Open Font Format) einbettet und wo nötig CSS-Transformationen verwendet. Das Ergebnis ist eine Webseite, die vom Original-PDF nicht zu unterscheiden ist, doch das zugrunde liegende HTML ist eine Wand aus position: absolute-Spans ohne jede semantische Bedeutung.

Layouttreue versus semantischer Fluss, der zentrale Kompromiss

Das ist der zentrale Kompromiss bei der PDF-zu-HTML-Umwandlung: Sie können Layouttreue haben oder semantischen Fluss, aber beides zugleich ist schwer zu haben. Ein treuebetonter Konverter wie pdf2htmlEX erzeugt eine Ausgabe, die wie das Original aussieht und druckt, aber für einen Screenreader undurchsichtig und auf einem Handybildschirm starr ist. Ein flussbetonter Konverter wie pdftotext oder PDF.js' getTextContent, gefolgt von einer einfachen Absatzrekonstruktion, erzeugt sauberes, lesbares, barrierefreies HTML, verliert aber den visuellen Reichtum der Quelle: Farben, exakte Schriften, Bildplatzierung, Tabellengitter und jedes Gespür für die ursprüngliche Seite.

Das Absolutool-Tool steht klar auf der flussbetonten Seite. Es extrahiert den Textinhalt mit PDF.js und gibt ihn als Absätze aus, wobei es Lesbarkeit, Barrierefreiheit und geringe Dateigröße über eine pixelgenaue Reproduktion stellt. Wenn Sie den Weg der visuellen Reproduktion brauchen (jeder Glyph an seiner Originalposition, Originalschriften eingebettet, exakte Seitenaufteilung erhalten), ist pdf2htmlEX das Werkzeug, das Sie sich ansehen sollten; wenn Sie den Weg der lesbaren Absätze brauchen (Wiederverwendung von Inhalten, Web-Veröffentlichung, suchindexierbares HTML, screenreader-barrierefreie Ausgabe), ist dieses Tool genau richtig.

Eingebettete Schriften, Bilder und der Vektorinhalt darunter

Ein PDF kann jede beliebige Schrift einbetten, und ein Konverter, der das Originalbild bewahren möchte, hat drei Möglichkeiten. Einbetten und ausliefern: Der Konverter extrahiert jede eingebettete Schrift aus dem PDF, verpackt sie als Web-Schrift in einem Format, das Browser verstehen (WOFF oder, seit 2018, WOFF2 mit seiner aggressiveren Brotli-Kompression), und verlinkt sie aus dem erzeugten HTML. Das bewahrt das Originalbild, bläht aber die Dateigröße auf und kann auf Lizenzprobleme stoßen, wenn die Einbettungsrechte der Schrift nicht bis zur Web-Weiterverbreitung reichen. Ersetzen: Jede eingebettete Schrift einer ähnlichen Systemschrift zuordnen (eine Serifen-PDF-Schrift könnte zu Times New Roman oder Georgia werden) und dabei eine gewisse visuelle Abweichung gegen eine kleinere, sauberere Ausgabe eintauschen. Ignorieren: Schriftinformationen vollständig verwerfen und den Browser eine Standard-Fließschrift anwenden lassen, was die meisten flussbetonten Konverter tun, weil der Nutzer das HTML in der normalen Darstellung des Browsers liest.

Bilder stellen vor eine ähnliche Wahl. Ein Konverter kann eingebettete Bilder als separate Dateien extrahieren und aus dem HTML referenzieren; ganze Seiten als Bilder rastern und inline einbetten (und das PDF in eine aufgemotzte Galerie verwandeln); oder Bilder vollständig weglassen und nur Text ausgeben, was die Wahl dieses Tools ist, passend zur Wiederverwendung von Inhalten statt zur visuellen Reproduktion. Vektorinhalt (Linien, Formen, Pfade, die von den Grafikoperatoren des PDF gezeichnet werden) ist noch heikler, weil es keinen sauberen Weg gibt, ihn in semantischem HTML darzustellen; Konverter, die ihn bewahren wollen, greifen meist auf Inline-SVG oder PNG-Rasterung zurück.

Wenn das PDF ein Bild ist: OCR als Rückfalllösung für gescannte Dokumente

Ein erheblicher Anteil der PDFs in freier Wildbahn sind im strukturierten Sinn gar keine richtigen Dokumente, sondern gescannte Bilder von Papierdokumenten, in PDF-Hüllen verpackt, weil PDF das universelle Format ist, um papierartige Dinge über das Internet zu versenden. Ein gescanntes PDF hat keinen Text-Content-Stream; jede Seite ist ein einziges eingebettetes Rasterbild, das zwar Text abbildet, ihn aber nicht als maschinenlesbare Zeichen enthält. Das Extrahieren von Text aus einem solchen PDF erfordert optische Zeichenerkennung (OCR), was eine grundlegend andere Operation ist als die Textextraktion.

Die vorherrschende Open-Source-OCR-Engine ist Tesseract, ursprünglich zwischen 1985 und 1995 in den HP Labs entwickelt, 2005 quelloffen gemacht und von 2006 an von Google gepflegt, bis Google die Hauptverantwortung um 2018 an eine Community-Gruppe übergab. Tesseract unterstützt mehr als hundert Sprachen, läuft auf jeder größeren Plattform und treibt die OCR-Funktionen unzähliger Desktop- und Server-Werkzeuge an. Apples Vision-Framework, seit 2017 unter macOS und iOS verfügbar, enthält eine schnelle und genaue Texterkennungs-API, die von den eingebauten Screenshot- und Foto-Apps des Betriebssystems genutzt wird. Google Cloud Vision, Azure Computer Vision und Amazon Textract sind die großen Cloud-OCR-Dienste; speziell für Dokumente gehen Textract und Azures Document Intelligence über reine OCR hinaus und erkennen Tabellen, Schlüssel-Wert-Paare und Formularfelder.

Ein browserbasierter PDF-zu-HTML-Konverter, der vollständig clientseitig läuft, kann im Allgemeinen keine OCR durchführen, denn die OCR-Modelle sind mindestens zig Megabyte groß und die Inferenz ist zu langsam, um interaktiv auf dem Laptop eines Nutzers zu laufen. Wenn Ihr PDF gescannte Seiten ohne extrahierbaren Text enthält, erzeugt dieses Tool für diese Seiten eine leere Ausgabe, und der richtige nächste Schritt ist ein separates OCR-Werkzeug oder ein serverseitiger Dienst.

Warum Menschen PDFs in HTML umwandeln

Die Anwendungsfälle lassen sich in eine Handvoll wiederkehrender Muster einordnen:

Jeder dieser Fälle hat etwas andere Anforderungen, doch sie teilen einen gemeinsamen Faden: Der Nutzer will den Inhalt des PDF (die Wörter, die Struktur, die Bedeutung), ohne durch das starre, seitengebundene Format eingeschränkt zu sein, das das Originaldokument gewählt hat.

Weitere Fragen

Warum sieht mein umgewandeltes HTML anders aus als das Original-PDF?

Dieses Tool ist flussbetont: Es extrahiert den Text und gibt saubere Absätze in der Standardschrift Ihres Browsers aus, wobei es Lesbarkeit, Barrierefreiheit und Suchindexierbarkeit über visuelle Treue stellt. Wenn Sie eine pixelgenaue Reproduktion des ursprünglichen Layouts brauchen (eingebettete Schriften, exakte Positionierung, Originalfarben), sehen Sie sich treuebetonte Werkzeuge wie pdf2htmlEX an, das absolut positionierte div-Elemente ausgibt, die dem Quell-PDF visuell entsprechen, aber HTML erzeugen, das für Screenreader im Grunde unlesbar und auf Handybildschirmen starr ist.

Warum kommt mein mehrspaltiges PDF durcheinander heraus?

PDF speichert keine Lesereihenfolge, nur Positionen. Ein Konverter muss Spaltengrenzen aus der räumlichen Verteilung des Textes ableiten. Bei einfachen zweispaltigen Layouts funktioniert die Heuristik meist; bei komplexen Layouts mit Randnotizen, Fußnoten, die sich mit dem Fließtext verschachteln, oder Text, der eine Spaltenrinne überquert, kann sie eine Ausgabe in falscher Reihenfolge erzeugen. Wenn Sie ein ausgezeichnetes PDF haben (eines, das einen Strukturbaum enthält), ist die Genauigkeit drastisch besser; bei nicht ausgezeichneten PDFs hängt das Ergebnis davon ab, wie klar die Spalten physisch durch Weißraum getrennt sind.

Mein PDF ist gescannt (nur Bilder), warum wird nichts extrahiert?

Ein gescanntes PDF hat keinen Textinhalt, jede Seite ist ein Rasterbild von Text statt Text, den der Parser lesen kann. Die Textextraktion erfordert OCR (Tesseract, Google Cloud Vision, Apples Vision-Framework usw.), was eine grundlegend andere Operation ist als das PDF-Parsing. Dieses Tool bündelt keine OCR-Engine, weil die Modelle zu groß sind, um sie mit einem Browser-Werkzeug auszuliefern. Der richtige nächste Schritt ist ein dedizierter OCR-Dienst oder ein Desktop-Werkzeug mit eingebauter OCR.

Kann ich ein passwortgeschütztes PDF umwandeln?

Wenn das PDF ein Öffnungspasswort hat (Sie müssen schon zum Betrachten ein Passwort eingeben), wirft PDF.js einen Fehler, statt umzuwandeln. Hat das PDF nur ein Berechtigungspasswort (das Öffnen ist frei, aber Drucken/Kopieren sind eingeschränkt), variiert das Verhalten; die meisten modernen PDF.js-Builds respektieren die Berechtigungen und verweigern möglicherweise die Textextraktion. So oder so ist der sauberste Weg, den Schutz zuerst im ursprünglichen PDF-Werkzeug zu entfernen und dann umzuwandeln. Den Schutz eines PDF zu entfernen, das Ihnen rechtmäßig gehört, ist in Ordnung; bei einem PDF, das Ihnen nicht gehört, möglicherweise nicht.

Verwandte Tools

Text zu CSV

Tabellarische Daten in CSV konvertieren.

Base64-Encoder

Dateien in Base64 kodieren.

JSON-Formatter

JSON formatieren und validieren.