HTML zu PDF konvertieren — Webseite online als PDF speichern

Einen Artikel zum Offline-Lesen speichern, ein fertiges E-Mail-Layout an einen Bericht anhängen, eine PDF-Version Ihrer Webseite oder einer Quittung aus HTML-Code erstellen — eine häufige Aufgabe. Das Werkzeug „HTML → PDF" in pdfredX erledigt das direkt im Browser und lässt Sie wählen, wie: privat (lokal) oder mit besserem Layout (über einen Server). Sehen wir uns beide Wege an.

Schritt 01. Das Werkzeug öffnen

Öffnen Sie pdfredx.com und starten Sie „HTML → PDF". Es erscheint ein Fenster mit zwei Reitern: HTML-Code (fertige Auszeichnung einfügen) und Seiten-URL (eine Webadresse). Wählen Sie, was Sie haben.

Schritt 02. Die Konvertierungsmethode wählen

Unter dem Eingabefeld ist ein Methoden-Umschalter:

• 🔒 Lokal (privat). Die Konvertierung läuft direkt in Ihrem Browser, die Datei geht nirgendwohin. Die beste Wahl für eingefügten HTML-Code, dessen Stile und Bilder darin enthalten sind (inline-CSS, data-Bilder).
• 🌐 Server (besseres Layout). Die Auszeichnung oder die Seite unter einer URL wird von unserem Server gerendert. Er hält Layout und externe Ressourcen besser, ist aber ein einfacher Render ohne JavaScript — gut für Dokumente und einfache Seiten, schwach bei komplexen dynamischen Websites. Wird auf unserem Server verarbeitet (nicht 100% lokal).
• Für den Reiter URL ist die „lokale" Methode 🖨 Öffnen + Strg+P: Wir öffnen die Seite in einem neuen Tab, und Sie drücken Strg+P → „Als PDF speichern". Das ergibt die beste Qualität (die Engine Ihres Browsers) und bleibt 100% lokal.

Schritt 03. Das PDF erhalten

Klicken Sie auf „In PDF konvertieren" — die fertige Datei wird direkt aus dem Browser heruntergeladen. So wird aus HTML-Code ein sauberes Dokument und aus einer Adresse eine PDF-Version der Website oder eine Webseite als Offline-Dokument. Kostenlos, ohne Registrierung.

Wie es technisch funktioniert

Der lokale Weg. Das eingefügte HTML wird in einem versteckten Container gerendert, dann erfasst html2canvas es in ein Bild, und jsPDF baut das PDF (ein A4-Blatt, eine lange Seite über mehrere geschnitten). Alles im Speicher des Tabs — nichts wird gesendet.

Der Server-Weg. Der Code oder eine per URL geladene Seite wird an unseren PHP-Endpunkt gesendet, wo die Bibliothek Dompdf ein echtes PDF rendert und zurückgibt. Der Server kann, anders als der Browser, eine Seite per URL laden (der Browser wird davon durch die CORS-Richtlinie abgehalten).

Bekannte Einschränkungen

Lokal — nur in sich geschlossenes HTML. Externe Bilder und Stile von anderen Domains werden in diesem Modus nicht geladen (Sicherheitsrichtlinie). Für Seiten mit externen Ressourcen nutzen Sie den Server oder Strg+P.

Der Server führt kein JavaScript aus. Dompdf rendert HTML und CSS, führt aber keine Skripte aus — auf per JS gezeichneten Seiten wird das Ergebnis vereinfacht. Für solche Seiten liefert der Browser-Druck (Strg+P) das beste Ergebnis.

Eine Live-URL lässt sich nicht „lokal" konvertieren. Der Browser kann wegen CORS keine fremde Seite lesen — daher gibt es für eine URL entweder den Server oder den ehrlichen Weg „Öffnen + Strg+P".

Müssen Sie mehrere fertige PDFs zu einem verbinden? Das ist das Werkzeug PDFs zusammenführen.

Probieren Sie es gleich aus — pdfredx.com, ohne Registrierung.

Die meisten Online-HTML-zu-PDF-Generatoren funktionieren gleich: Sie geben ihnen Ihren Code oder eine Seitenadresse, alles geht an ihren Server, und eine Datei kommt zurück. Für eine öffentliche Seite ist das unbedenklich. Doch wenn das HTML einen internen Bericht, einen E-Mail-Entwurf, ein Layout mit Kundendaten oder Code mit sensiblen Informationen enthält, möchten Sie es nicht an eine fremde Maschine senden. pdfredX löst das ehrlich: Es bietet zwei Wege und sagt klar, welche Verarbeitung lokal und welche auf dem Server erfolgt.

Warum das wichtig ist

HTML-Code enthält oft nicht nur Layout, sondern Daten: Beträge in einer Quittung, personenbezogene Felder in einer E-Mail-Vorlage, interne Links, Kommentare in der Auszeichnung. Ein gewöhnlicher „HTML-zu-PDF-Generator" nimmt all das auf seinem Server entgegen, wo es nach der Richtlinie des Dienstes protokolliert und gespeichert werden kann.

Der DSGVO-Blickwinkel

Sobald der Code oder die Seite auf den Server eines Dienstes hochgeladen wird, findet — wenn personenbezogene Daten enthalten sind — im Sinne der DSGVO eine Übermittlung an einen Dritten statt, mitsamt der zugehörigen Pflichtenkette (AVV, Serverstandort, Rechtsgrundlage). Der lokale Weg dreht die Logik um: Verlassen Code und Daten das Gerät nicht, gibt es keine Übermittlung an einen Dritten — und die Pflichtenkette entfällt.

Weg 1. Lokal — privat, in Ihrem Browser

Wählen Sie die Methode 🔒 Lokal. Das eingefügte HTML wird direkt im Tab gerendert und in ein PDF verwandelt — die Datei verlässt das Gerät nicht.

• Nichts wird gesendet. Weder der Code noch die Daten gehen an einen Server.
• Funktioniert offline, sobald die App geladen ist.
• Am besten für in sich geschlossenes HTML: Stile und Bilder im Code (inline-CSS, data-Bilder).

Die ehrliche Einschränkung: Externe Ressourcen von anderen Domains werden in diesem Modus nicht geladen (Sicherheitsrichtlinie), und dies ist ein Weg für HTML-Code, nicht für eine Live-URL.

Weg 2. Server — besseres Layout, aber nicht 100% lokal

Wählen Sie die Methode 🌐 Server. Der Code oder die Seite unter einer Adresse wird von unserem PHP-Server mit der Bibliothek Dompdf gerendert.

• Hält Layout und externe Ressourcen besser als der lokale Weg.
• Beherrscht URLs: Der Server kann eine Seite per Link laden (dem Browser verbietet das CORS).
• Ehrlicher Hinweis: Es ist ein einfacher Render ohne JavaScript, und die Verarbeitung erfolgt auf unserem Server — nicht 100% lokal. Gut für Dokumente, Rechnungen, einfache Seiten; bei komplexen dynamischen Websites wird das Ergebnis vereinfacht.

Wir verstecken das bewusst nicht hinter vagen „100% privat"-Aussagen: Wenn Sie den Server gewählt haben, gehen die Daten an den Server. Die Wahl ist eine bewusste.

Weg 3 (für URLs). Browser-Druck — beste Qualität, lokal

Für den Reiter URL gibt es eine dritte, ehrlichste Option — 🖨 Öffnen + Strg+P. Wir öffnen die Seite in einem neuen Tab, Sie drücken Strg+P → „Als PDF speichern". Das ist die Engine Ihres Browsers: beste Qualität, volle Unterstützung von modernem CSS und JavaScript, und dennoch 100% lokal. Für Live-Websites ist das oft der optimale Weg.

Was wir nicht garantieren können — ein ehrlicher Hinweis

Der lokale Weg schützt Code und Daten davor, an externe Server zu gelangen, doch er ist kein Schild gegen jede Bedrohung. Schadsoftware auf dem Gerät, Browser-Erweiterungen mit weitreichenden Rechten und eine unverschlüsselte Festplatte bleiben außerhalb unserer Kontrolle. Der Server-Weg sendet nach Ihrer Wahl Daten an den Server — ein Kompromiss für die Layout-Qualität. Wählen Sie den Weg nach der Aufgabe: Privatsphäre — lokal; der beste Render einer Live-Website — Strg+P; komplexes statisches Layout — der Server.

Erstellen Sie ein PDF aus HTML so, wie Sie es brauchen — pdfredx.com, kostenlos, ohne Registrierung.

Die Konvertierung von HTML zu PDF ist eine Aufgabe mit drei grundlegend verschiedenen Engines, und jede hat ihren Preis. Das ideale Ergebnis liefert ein Headless-Browser (echtes Chrome rendert die Seite mit JS und modernem CSS) — doch das ist eine schwere Serverkomponente. In einem Browser ohne Backend ist der Raster-Weg über Canvas verfügbar. Und auf günstigem PHP-Hosting — ein reiner PHP-Render. pdfredX kombiniert bewusst die zwei realistischen Wege und trennt sie ehrlich nach Privatsphäre. Sehen wir uns die Architektur an.

Drei Engines und die harte CORS-Grenze

Headless Chrome — der Qualitätsmaßstab, braucht aber Node/Chromium auf dem Server; Shared Hosting hat das nicht. html2canvas + jsPDF — läuft im Browser, privat, rastert aber das DOM und lädt keine externen Ressourcen. Dompdf — reines PHP, überall installierbar, aber CSS 2.1 und kein JavaScript.

Die entscheidende Grenze, die alles bestimmt: Der Browser kann das HTML einer fremden Seite nicht lesen — die CORS-Richtlinie blockiert seitenübergreifende Anfragen. Deshalb ist „Live-URL eingeben → PDF erhalten" rein clientseitig unmöglich; eine URL wird entweder vom Server (der kein CORS hat) oder vom Browser selbst per Druck verarbeitet.

Weg 1. Lokaler Render: html2canvas → jsPDF

Das eingefügte HTML wird in einem versteckten Offscreen-Container gezeichnet, html2canvas erfasst es in ein <canvas>, und jsPDF baut das PDF, wobei eine lange Seite in A4-Blätter geschnitten wird:

await ensureHtml2Canvas();                     // verzögertes Laden von cdnjs
const canvas = await html2canvas(holder, { scale: 2, backgroundColor: '#fff' });
const pdf = new jsPDF({ unit: 'pt', format: 'a4' });
const imgH = canvas.height * (pw / canvas.width);
let heightLeft = imgH, position = 0;
pdf.addImage(canvas.toDataURL('image/jpeg', 0.92), 'JPEG', 0, position, pw, imgH);
while ((heightLeft -= ph) > 0) { position -= ph; pdf.addPage(); pdf.addImage(imgData, 'JPEG', 0, position, pw, imgH); }

Plus — 100% privat (nichts verlässt den Tab) und CSP-kompatibel (html2canvas von cdnjs ist in script-src erlaubt). Minus — das Ergebnis ist ein Raster, und externe Bilder/Stile von anderen Domains werden nicht geladen (CSP img-src/CORS). Daher ist der lokale Weg für in sich geschlossenes HTML (Stile und data-Bilder darin).

Weg 2. Server-Render: Dompdf + SSRF-Schutz

Der Code oder eine geladene Seite geht per POST an html2pdf.php, wo Dompdf das PDF rendert. Der Server kann, anders als der Browser, eine Seite per URL laden — doch das öffnet einen SSRF-Vektor (eine Anfrage an interne Adressen). Deshalb laufen sowohl unser Fetch als auch Dompdfs eigene Downloads durch einen Filter:

function isSafeUrl($url) {
  $p = parse_url($url);
  if (!in_array($p['scheme'], ['http','https'])) return false;   // nur http/https
  foreach (resolveIps($p['host']) as $ip)
    if (!filter_var($ip, FILTER_VALIDATE_IP, FILTER_FLAG_NO_PRIV_RANGE | FILTER_FLAG_NO_RES_RANGE))
      return false;                                              // private/reservierte IPs — abgelehnt
  return true;
}
$options->setAllowedProtocols(['http://'=>['rules'=>[$rule]], 'https://'=>['rules'=>[$rule]]]);

Dazu Redirects aus, Timeouts, Größenlimits, DejaVu-Schriften für Kyrillisch. Der Minus der Engine — CSS 2.1 und kein JavaScript: Auf JS-Seiten degradiert das Layout. Die Hosting-Diagnose bestätigte es (PHP 8.1, cURL/exec vorhanden, kein Headless-Browser) — daher die Wahl von Dompdf statt Chrome.

Weg 3 (für URLs). Browser-Druck als „bestes Lokales"

Für eine Live-Adresse ist der ehrlichste Weg, die Seite zu öffnen und Strg+P → „Als PDF speichern". Das ist die eigene Engine des Browsers: JS, modernes CSS, perfekte Typografie — und dabei 100% lokal. Hier ist der Server nicht „besser", er automatisiert nur (ein Klick), auf Kosten der Qualität.

Kompromisse und Grenzen

Was als Nächstes kommt. Eine optionale kostenpflichtige Headless-Chrome-API für alle, die einen perfekten automatischen Render einer Live-URL brauchen — als dritte Methode neben lokal und Dompdf.

Testen Sie beide Wege — pdfredx.com, ohne Registrierung.