Warum sieht mein PDF anders aus als die Webseite im Browser?

Meist liegt es an Druck-Stilen (@media print), die Elemente ausblenden oder umfärben, an nicht geladenen externen Ressourcen wie Bildern und Schriften oder an JavaScript, das zum Konvertierungszeitpunkt noch nicht fertig ausgeführt war. Das PDF bildet den Zustand zum Zeitpunkt des Renderns ab, nicht zwingend das, was Sie auf dem Bildschirm sehen.

Welche Seitengröße benutzt die Konvertierung standardmäßig?

In Europa ist A4 (210 × 297 mm) der übliche Standard. Über die CSS-Regel @page lassen sich Größe, Ausrichtung (Hoch- oder Querformat) und Seitenränder gezielt festlegen, etwa size: A4 landscape oder size: letter.

Werden Schriftarten ins PDF eingebettet?

Die Render-Engine bettet die tatsächlich verwendeten Schriften in der Regel als Untermenge (Subset) in die PDF-Datei ein, damit das Dokument überall gleich aussieht. Voraussetzung ist, dass die Schrift beim Rendern verfügbar war. Fehlt sie, wird auf eine Ersatzschrift zurückgegriffen.

Wie verhindere ich, dass ein Element mitten am Seitenrand zerschnitten wird?

Mit den CSS-Eigenschaften break-inside: avoid für das betroffene Element sowie break-before und break-after lässt sich der Umbruch steuern. So bleiben Tabellenzeilen, Bilder mit Bildunterschrift oder Codeblöcke zusammen auf einer Seite.

Wie ein PDF aus HTML entsteht: Rendering, CSS und Seitenumbruch

Wer eine Webseite als PDF speichert, erwartet meist ein Abbild dessen, was im Browser zu sehen ist. Tatsächlich steckt hinter dem Vorgang eine ganze Kette von Verarbeitungsschritten. HTML und CSS sind zunächst nur Text. Erst eine Render-Engine macht daraus eine sichtbare Seite, und erst ein weiterer Schritt verwandelt diese fließende Darstellung in feste, paginierte Seiten im PDF-Format. Wer diesen Weg versteht, weiß auch, warum manche Layouts im PDF überraschend anders wirken.

Von Text zu Darstellung: Was die Render-Engine tut

Am Anfang steht reiner Quelltext. Die Render-Engine, also dieselbe Software-Komponente, die auch im Browser für die Bildschirmdarstellung zuständig ist, durchläuft mehrere Phasen, bevor überhaupt ein Pixel gezeichnet wird.

Zuerst wird das HTML geparst und in den sogenannten DOM-Baum (Document Object Model) überführt. Das ist eine hierarchische Struktur aller Elemente: Überschriften, Absätze, Bilder, Tabellen. Parallel dazu wird das CSS eingelesen und zu einem Regelsatz verarbeitet, dem CSSOM. Beide Bäume werden anschließend zum Render-Baum kombiniert, der nur noch die tatsächlich sichtbaren Elemente enthält.

Im nächsten Schritt, dem Layout (auch Reflow genannt), berechnet die Engine für jedes Element seine genaue Position und Größe. Sie löst dabei alle Maßangaben auf: relative Einheiten wie Prozent oder em werden in konkrete Werte umgerechnet, Flexbox- und Grid-Container verteilen ihren Platz, Text wird in Zeilen gebrochen. Erst danach folgt das Paint, das eigentliche Zeichnen der Pixel beziehungsweise der Vektorinhalte.

Wichtig ist die Reihenfolge: Solange das Layout nicht abgeschlossen ist, steht nicht fest, wie viel vertikalen Platz der Inhalt einnimmt. Genau diese Information braucht der nächste Schritt.

Vom fortlaufenden Inhalt zur festen Seite

Im Browser ist eine Webseite ein endloser, vertikal scrollbarer Strom. Es gibt keine natürliche Grenze nach unten, der Inhalt fließt einfach weiter. Ein PDF dagegen besteht aus klar abgegrenzten Seiten mit fester Größe, in Europa typischerweise A4 mit 210 × 297 Millimetern.

Die Render-Engine muss diesen fortlaufenden Inhalt also in Seiten zerlegen. Dieser Vorgang heißt Pagination oder Seitenumbruch. Vereinfacht gesagt legt die Engine eine virtuelle Seitenhöhe fest, füllt sie von oben mit Inhalt und beginnt eine neue Seite, sobald der verfügbare Platz erschöpft ist. Was nicht mehr passt, rutscht auf die Folgeseite.

Gesteuert wird das über das CSS-Modul Paged Media. Mit der Regel @page lassen sich Seitengröße, Ausrichtung und Ränder bestimmen:

size: A4 oder size: A4 landscape legt Format und Ausrichtung fest.
margin bestimmt die Seitenränder, also den weißen Rand um den Inhaltsbereich.
@page :first erlaubt abweichende Regeln für die erste Seite, etwa für ein Deckblatt.

Ohne diese Angaben greift die Konvertierung auf Standardwerte zurück, also meist A4 im Hochformat mit moderaten Rändern. Das erklärt, warum ein ungestyltes Dokument oft brauchbar aussieht, das Feintuning aber gezielte Regeln erfordert.

Umbruch-Steuerung: Damit nichts zerrissen wird

Der automatische Seitenumbruch ist praktisch, kann aber unschöne Ergebnisse liefern. Eine Tabellenzeile wird mittendrin getrennt, eine Überschrift landet einsam am Seitenende, ein Bild wird von seiner Bildunterschrift abgekoppelt. Hier greifen die Umbruch-Eigenschaften von CSS:

break-inside: avoid hält ein Element zusammen, sodass es nicht zwischen zwei Seiten zerschnitten wird.
break-before: page erzwingt einen Umbruch vor einem Element, etwa um jedes Kapitel auf einer neuen Seite zu beginnen.
break-after: avoid verhindert einen Umbruch unmittelbar nach einem Element, was Überschriften an ihren folgenden Absatz bindet.

Auch die älteren Eigenschaften widows und orphans spielen eine Rolle. Sie legen fest, wie viele Zeilen eines Absatzes mindestens am Seitenende oder am Seitenanfang stehen müssen, damit keine einzelne, verwaiste Zeile übrig bleibt. Wer ein PDF professionell aussehen lassen will, kommt um diese Steuerung kaum herum.

Schriften und JavaScript: Zwei häufige Stolpersteine

Schriftarten sind ein eigener Themenkomplex. Damit ein PDF überall identisch aussieht, bettet die Render-Engine die verwendeten Schriften direkt in die Datei ein, üblicherweise als Subset, also nur die tatsächlich benötigten Zeichen. Das hält die Datei klein und sorgt für ein verlässliches Schriftbild unabhängig davon, welche Schriften auf dem öffnenden Gerät installiert sind.

Voraussetzung ist allerdings, dass die Schrift zum Renderzeitpunkt geladen war. Wird eine Web-Schrift von einem externen Server nachgeladen und ist dieser Ladevorgang noch nicht abgeschlossen, kann die Engine auf eine Ersatzschrift ausweichen. Das Ergebnis: Im PDF steht plötzlich eine andere Schriftart als erwartet.

Ähnlich verhält es sich mit JavaScript. Moderne Webseiten bauen Inhalte oft erst nachträglich im Browser auf, etwa Diagramme, dynamisch geladene Listen oder interaktive Elemente. Die Konvertierung erfasst nur den Zustand zu einem bestimmten Moment. Hat das Skript seine Arbeit zu diesem Zeitpunkt noch nicht beendet, fehlen die entsprechenden Inhalte im PDF oder erscheinen unvollständig. Eine gute Konvertierung wartet daher, bis Netzwerk und Skripte zur Ruhe gekommen sind, bevor sie die Seite einfriert.

Warum das PDF anders aussieht als der Bildschirm

Der vielleicht häufigste Aha-Moment: Das fertige PDF weicht sichtbar von dem ab, was im Browserfenster zu sehen war. Dafür gibt es mehrere nachvollziehbare Gründe.

Der wichtigste sind die Druck-Stile. CSS kennt mit @media print einen eigenen Block, der nur beim Drucken oder bei der PDF-Erzeugung greift. Viele Webseiten nutzen ihn bewusst, um Navigationsleisten, Werbung, Buttons oder Hintergrundfarben auszublenden und den Inhalt drucktauglich aufzubereiten. Was am Bildschirm bunt und interaktiv ist, erscheint im PDF dann reduziert. Das ist meist gewollt, kann aber überraschen, wenn man es nicht erwartet.

Ein weiterer Grund sind externe Ressourcen. Bilder, Schriften oder Stylesheets, die von fremden Servern geladen werden, stehen zum Konvertierungszeitpunkt nicht immer zur Verfügung. Blockiert eine Zugriffsbeschränkung den Abruf oder antwortet ein Server zu langsam, fehlt das betreffende Element im Ergebnis.

Hinzu kommt der Unterschied zwischen Bildschirm- und Druckmodell. Der Browser passt sich der Fensterbreite an und reagiert auf responsive Layouts. Die PDF-Seite dagegen hat eine feste Breite. Ein Layout, das für einen breiten Monitor optimiert ist, wird auf die schmalere A4-Breite umgebrochen, wodurch Spalten umbrechen oder Inhalte enger zusammenrücken.

Die Rolle von Print-CSS

Print-CSS ist der Hebel, mit dem sich das PDF gezielt formen lässt. Wer die Kontrolle über das Ergebnis behalten will, definiert eigene Regeln im @media print-Block. Typische Maßnahmen sind:

Störende Bildschirm-Elemente per display: none ausblenden.
Hintergrundfarben und Farbverläufe für den Druck anpassen oder durch print-color-adjust: exact erzwingen.
Linkadressen sichtbar machen, indem die URL hinter dem Linktext ausgegeben wird.
Seitenumbrüche über break-before und break-inside an sinnvolle Stellen legen.

Eine Webseite, die solche Druck-Stile mitbringt, liefert ein deutlich besseres PDF als eine, die nur für den Bildschirm gestaltet wurde. Wer selbst HTML für die Konvertierung erstellt, sollte den Druckfall von Anfang an mitdenken und das Ergebnis testen, statt sich auf das Bildschirm-Layout zu verlassen.

Unterm Strich ist die PDF-Erzeugung aus HTML ein Übersetzungsvorgang zwischen zwei Welten: dem flexiblen, fließenden Web und dem festen, seitenbasierten Druck. Jede Stufe, vom Parsen über das Layout bis zur Pagination, hat Einfluss auf das Endergebnis. Wer weiß, an welchen Stellen die beiden Modelle auseinanderlaufen, kann gezielt nachsteuern.

Worauf es ankommt

Ein PDF aus HTML entsteht nicht durch bloßes Abspeichern, sondern durch Rendern, Auswerten der Stile und Umbrechen auf feste Seiten. Die größten Abweichungen vom Bildschirm erklären sich durch Druck-Stile, fehlende externe Ressourcen und nicht fertig ausgeführtes JavaScript. Wer A4-Format, Seitenumbruch und Schriften bewusst über CSS steuert und Print-Stile von Anfang an einplant, erhält ein verlässliches, sauber paginiertes Ergebnis statt eines zufälligen Abbilds.