HTML in PDF

So wandeln Sie HTML in drei Schritten in PDF um

Schritt eins: Fügen Sie Ihr Markup ein oder importieren Sie eine gespeicherte .html-Datei. Das Markup wird in seinem eigenen Rahmen gesetzt, getrennt von dieser Seite – Stile dieser Seite vermischen sich nicht mit Ihren. Sie können Dateien per Drag-and-drop ablegen oder klicken, um sie auf Ihrem Gerät zu wählen.

Schritt zwei: Prüfen Sie die Vorschau, dass die Ansicht stimmt. Der Browser rendert sie, dann wird jede finale PDF-Seite ein PNG-Bild dieses Renderings. Das Rendering läuft in doppelter Endgröße, etwa 144 dpi. Genug für Bildschirm und Bürodrucker; für den Akzidenzdruck werden Pixel sichtbar.

Schritt drei: Klicken Sie auf Herunterladen, um das PDF direkt aus dem Speicher zu sichern. Das Tool ist kostenlos und sicher: ohne Installation, ohne Anmeldung – und Ihr HTML verlässt nie diesen Tab. Wissen Sie von Anfang an: Text ist nicht wählbar, Strg+F findet nichts in der Ausgabe, und Screenreader erhalten nichts.

Wann ein Bild die richtige Antwort ist

Rasterung ist eine schlechte Idee für Verträge, die jemand durchsuchen muss. Sie funktioniert gut, wenn die Seitenansicht der Punkt ist.

Markup einfügen ist nicht Datei öffnen

Die .html-Import-Schaltfläche liest nur Text aus genau dieser Datei, nicht mehr. Stylesheets daneben, Logos in ./images, Webfonts in ./fonts: Nichts davon kommt mit, weil der Browser einer Webseite nicht den Rest Ihrer Platte übergibt.

Relative Pfade scheitern lautlos. Ihr Markup rendert hier, nicht im Ordner, wo die Datei liegt – src="logo.png" wird relativ zu oxygenpdf.com aufgelöst und findet nichts. Absolute https://-URLs laden, sofern der Server CORS-Header zurückgibt.

Skripte laufen nie. So hinzugefügtes Markup führt seine Skript-Tags nicht aus – eine aus dem Browser gespeicherte Single-Page-App wirkt fast leer. Was Sie sichern, ist die Hülle, nicht das Rendering. Kopieren Sie stattdessen das lebendige DOM aus dem Elementprüfer und fügen Sie das ein. Verlässlich mit kommt nur Eigenständiges: dateiinterne Stilblöcke, Inline-Stilattribute und Bilder als Daten-URIs.

Der Vergleich

Drei Wege, HTML ins PDF zu bringen – jeweils mit eigenen Nachteilen.

Was erhalten bleibt – und wo Seiten umbrechen

Farben, Verläufe, Rahmen, runde Ecken, Kastenschatten, Deckkraft, CSS-Transformationen, Textschatten, Tabellen, Listen und Inline-SVG kommen alle mit. Der Renderer zeichnet jede Box selbst neu, statt das Betriebssystem um einen Screenshot zu bitten – eine Handvoll neuerer Effekte ohne direktes Gegenstück wird darum warnungslos verworfen: Filter und ihr blur(), mix-blend-mode, backdrop-filter, clip-path und Masken.

Ihr Markup wird in einem Viewport von etwa 515 Pixeln Breite gesetzt – der Inhaltsbreite von A4, gemessen in CSS-Pixeln. Responsive Seiten rendern also an ihrem schmalen Breakpoint, und @media (min-width: 768px)-Regeln zünden nie. Wirkt Ihr Layout nur über 768 Pixeln korrekt, wirkt es hier nicht korrekt.

Das lange Finalbild wird in festen Abständen in seitenhohe Stücke geschnitten. Das Schneiden ist mechanisch und achtet nicht auf Inhalte darunter – Tabellenzeilen oder Titel können halb auf einer, halb auf der nächsten Seite landen. CSS-page-break-inside-Regeln helfen nicht; schieben Sie Ungeschicktes mit Extramargen oder Abstandshaltern über die Grenze. Etwa 762 Punkte Inhalt passen auf jede Seite.

Ihr HTML verlässt nie diesen Tab

Jeder serverseitige Konverter braucht Ihr Markup auf seiner Maschine. Entweder fügen Sie es in ein Formular ein und laden es hoch, oder Sie geben eine URL und sein Crawler holt die Seite – für Inhalte hinter Logins heißt der zweite Weg auch, Zugangsdaten zu übergeben. Beides ist kein bequemer Tausch für Bildschirme voller Kundennamen oder für noch unveröffentlichte Staging-Builds.

Das gesamte Rendering läuft im bereits geöffneten Tab: Der Renderer zeichnet Ihr Markup, die PDF-Bibliothek setzt Seiten zusammen, und der Download kommt direkt aus dem Speicher. Nichts im Netzwerk trägt Ihr HTML irgendwohin. Schließen Sie den Tab, und alles ist weg.