Von: HTML Nach: PDF

HTML zu PDF — ein API-Call, statt Headless-Chrome zu pflegen

Wandle beliebiges HTML (inkl. CSS, Web Fonts, Bilder und Tabellen) in ein sauberes PDF um. Optional auf deinem Briefpapier, optional PDF/A-konform, immer ohne eigenes Browser-Deployment.

Was es macht

Die API nimmt einen HTML-String (oder eine URL) entgegen und liefert ein PDF zurück. Die Rendering-Engine rendert modernes CSS — Flexbox, Grid, Web Fonts, @media print — genauso wie ein aktueller Chromium, nur serverseitig und stateless.

Minimaler Request

curl -X POST https://api.dokmatiq.com/v1/convert/html-to-pdf \
  -H "Authorization: Bearer $DOKMATIQ_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "html": "<!doctype html><html><body><h1>Rechnung 2026-0042</h1><p>Betrag: 960,00 €</p></body></html>",
    "format": "A4",
    "margins": { "top": "20mm", "bottom": "20mm", "left": "20mm", "right": "20mm" }
  }' \
  -o rechnung.pdf

Response: Content-Type: application/pdf, Status 200, Body = fertiges PDF.

Typische Optionen

{
  "html": "...",
  "format": "A4",
  "orientation": "portrait",
  "margins": { "top": "20mm", "bottom": "20mm", "left": "20mm", "right": "20mm" },
  "header": { "html": "<div style=\"font-size:9pt\">Rechnung 2026-0042</div>", "height": "15mm" },
  "footer": { "html": "<div style=\"font-size:9pt\">Seite <span class=\"pageNumber\"></span> von <span class=\"totalPages\"></span></div>", "height": "15mm" },
  "outputProfile": "PDF/A-3b",
  "waitUntil": "networkidle0"
}

Für Briefpapier-Overlay: die passenden Content-Areas im DocGen-Request setzen (stationery-Feld) statt im HTML — so bleibt der HTML-Code frei vom Layout und das Briefpapier ist 1:1 das, was die Grafikagentur geliefert hat.

Input-Grenzen

	Grenze
Maximale HTML-Größe	25 MB
Maximale Response-Größe	200 MB
Timeout bis Render-Fertig	60 s
Externe URLs (Bilder, Fonts)	folgen `https://` und `data:`
JavaScript-Ausführung	opt-in via `executeJs: true`

Standardmäßig rendert die API ohne JavaScript-Ausführung — deutlich schneller und vorhersehbarer als ein voller Headless-Browser. Wer dynamische Inhalte braucht (Charts, Client-Rendering), aktiviert das per Flag.

Wofür man es einsetzt

Rechnungs-PDFs aus Template-Engines wie Liquid, Handlebars, Twig
Reports aus Dashboard-Templates, die sowieso als HTML gerendert werden
E-Mail-Anhänge (Bestellbestätigung, Versandbenachrichtigung) aus den bestehenden Mail-Templates
Geschäftsbriefe auf Firmenbriefpapier, generiert aus CMS-Inhalten
Produktdatenblätter, Angebote, Verträge aus strukturierten Daten

Vergleich mit Alternativen

	Dokmatiq HTML-zu-PDF	Eigener Headless-Chrome	wkhtmltopdf	Pandoc
Setup-Zeit	1 API-Call	Container, Browser, Queue	Binary installieren	Binary installieren
Moderne CSS (Grid, Flex)	ja	ja	teilweise	via LaTeX begrenzt
Web Fonts	ja	ja	ja	eingeschränkt
Skalierung	API-seitig	selbst zu lösen	selbst zu lösen	selbst zu lösen
Briefpapier-Overlay	ja (via Stationery)	selbst bauen	nein	nein
PDF/A-Output	direkt per Flag	extra Post-Processing	extra Post-Processing	via LaTeX
JS-Rendering	opt-in	immer	nein	nein

Die eigene Chrome-Lösung ist fast immer verlockend — bis der erste Pod out-of-memory geht, ein Font-Request hängt oder Chrome ein Breaking-Update bringt. Dann zahlt man die Betriebskosten.

Häufige Stolpersteine

Web Fonts nicht geladen — waitUntil: "networkidle0" erzwingen oder Fonts als data:-URL einbetten
Seitenumbrüche ignoriert — page-break-after: always oder break-after: page (modernes CSS) explizit setzen
Relative URLs — die API sieht nicht, von welcher Domain das HTML kommt; Bilder/Fonts auf absolute URLs umstellen
Header/Footer zu klein — Header- und Footer-HTML rendert in einer kleineren Skala; font-size explizit setzen (mind. 8–9pt)

Direkt ausprobieren

100 Konvertierungen pro Monat kostenlos. Keine Kreditkarte. Stateless REST — du sendest, du bekommst.

Kostenlos starten OpenAPI-Doku