Eine PDF-Generierungs-API auszuwählen wirkt einfach, bis man beginnt. Es gibt rund 40 Anbieter, die Marketingseiten klingen ähnlich, und die echten Trade-offs lernen Sie oft erst nach einigen tausend Dokumenten in Produktion kennen.

Diese Checkliste können Sie in eine Anbieterbewertung mitnehmen: herstellerneutral und aus den realen Vorfällen abgeleitet, die Teams in Beschaffung und Post-mortems sehen. Acht Fragen; wenn Sie darauf keine klaren Antworten bekommen, haben Sie noch nicht genug Informationen für eine belastbare Entscheidung.

1. Welches Eingabeformat: HTML, JSON oder Template-DSL?

Das ist die wichtigste Frage. Die Antwort bestimmt, was Ihr Team schreibt und was es um 2 Uhr morgens debuggt.

HTML/CSS (Puppeteer, DocRaptor, Prince): vertraut, praktisch unbegrenzt flexibel, teuer zur Laufzeit und schwer deterministisch zu machen.
JSON / strukturierte Daten (gPdf): günstig zu rendern, byte-identisch, erfordert aber einen kleinen Mapper von Ihrem Datenmodell in das Dokumentmodell.
Template-DSL (PDFKit, ReportLab, Apache PDFBox): volle Kontrolle, aber auch volle Verantwortung. Pagination, Layout und Font-Fallback schreiben Sie selbst.

Es gibt keine falsche Antwort. Es gibt nur eine falsche Antwort für Ihr Team. Fragen Sie Ihre Entwickler, in welchem Modell sie lieber einen dreistündigen Pagination-Bug debuggen würden.

2. Wie hoch ist die Cold-Start-Latenz, und ist sie vorhersehbar?

Einige Renderer starten in Mikrosekunden, etwa WASM- oder native Binary-Ansätze. Andere starten in Sekunden, vor allem Chromium-basierte Stacks. Der Unterschied bleibt unsichtbar, bis Sie eine Lastspitze haben.

Fragen Sie den Anbieter:

“Wie hoch ist Ihre p99-Latenz für den ersten Request an einen kalten Worker?”
“Wie lange nach meinem letzten Request wird ein Worker wieder kalt?”
“Veröffentlichen Sie eine Statusseite mit Cold-Start-Daten?”

Wenn die erste Frage nicht mit einer Zahl beantwortet werden kann, planen Sie pessimistisch.

3. Wie wird der Preis pro Render modelliert?

Drei Modelle begegnen Teams besonders häufig, in der Reihenfolge, in der sie später Probleme machen:

Preis pro Seite (Anvil mit 0,10 USD/PDF, DocRaptor mit 89 USD/100.000): planbar, einfach zu budgetieren, bei Skalierung teuer.
Abostufen mit Overage (gPdf mit 5 bis 12 USD/Monat plus 0,00005 USD pro zusätzlicher Seite): bei jedem Volumen günstig, aber schwerer zu prognostizieren, wenn Sie die Nutzung noch nie gemessen haben.
Compute-basierte Kosten (selbst gehostetes Puppeteer auf Lambda): Sie tragen die Compute-Rechnung direkt, inklusive Cold Starts und Chromium-Speicher.

Rechnen Sie vor Vertragsabschluss Ihre echte Rechnung auf drei Traffic-Stufen durch: aktuelles Volumen, 5x und 50x. Die Form der Kostenkurve ist wichtiger als der beworbene Einstiegspreis.

4. Ist die Ausgabe deterministisch?

Determinismus - gleiche Eingabe -> gleiche Bytes - klingt akademisch, bis Sie ihn brauchen.

Sie brauchen ihn, wenn:

Sie PDFs in CI vergleichen, um unbeabsichtigte Vorlagenänderungen zu erkennen.
Sie Dokumente unter E-Rechnungs- oder Steueraufbewahrungspflichten behalten und das gespeicherte PDF zum neu gerenderten PDF passen muss.
Sie das PDF für Archivintegrität hashen.
Sie gerenderte Ausgaben für rechtliche Reviews versionieren.

Browserbasierte Renderer wie Puppeteer oder alles auf Chromium-Basis sind über Patch-Versionen hinweg NICHT deterministisch. Native Binary Renderer wie Prince oder gPdf sind es in der Regel. Fragen Sie ausdrücklich: “Ändern sich meine Ausgabe-Bytes, wenn Sie ein Renderer-Update ausrollen?”

5. Wie behandelt der Renderer Fonts, besonders CJK und RTL?

Diese Frage hat im PDF-Bereich mehr Karrieren gekostet als fast jede andere.

Der Ausfallmodus ist immer ähnlich: Sie starten im Heimatmarkt, Fonts sehen gut aus. Sechs Monate später expandieren Sie in einen Markt mit einem Schriftsystem, für das der Renderer keine Glyphen hat. Das PDF gibt □□□□ aus. Der Kunde eskaliert. Ihr Team verbringt zwei Sprints damit, Fonts in ein Dockerfile zu bekommen.

Fragen Sie:

“Welche Schriftsysteme sind ohne zusätzliche Konfiguration gebündelt? Lateinisch, CJK, Kyrillisch, Devanagari, Arabisch, Hebräisch?”
“Was passiert bei einem unbekannten Glyph: Fallback oder Tofu?”
“Kann ich Custom Fonts zur Request-Zeit hinzufügen, oder müssen sie vorher deployed werden?”
“Unterstützen Sie RTL Text Shaping?”

Eine gute Antwort lautet etwa: “Wir betten NotoSans CJK und ein Noto-Fallback-Set ein; unbekannte Glyphen fallen auf Noto Symbols zurück.” Eine schlechte Antwort lautet: “Ja, Fonts unterstützen wir.”

6. Welche Compliance-Profile werden unterstützt?

Wenn Ihr Unternehmen irgendwann Folgendes tun könnte:

Rechnungen in der EU ausstellen (Factur-X / ZUGFeRD / EN 16931, in DE/FR/IT/PL bis 2026 verpflichtend),
Dokumente unter SOX-, HIPAA- oder GDPR-Aufbewahrungsregeln archivieren (PDF/A),
medizinische Datensätze einreichen (PDF/A-3 mit angehängtem XML),
digitale Signaturen einbetten (PAdES),

…dann fragen Sie, welche Compliance-Profile der Renderer nativ unterstützt. Die schlechte Antwort lautet: “Sie können danach ein anderes Tool zur Konvertierung ausführen.” Das ist eine mehrstufige Pipeline, die Sie nun selbst besitzen.

Gute Antworten sehen meistens wie ein einzelnes Flag aus. gPdf nimmt zum Beispiel settings.profile: "pdfa-3b" plus einen settings.e_invoice-Block mit standard: "factur_x" und eingebettetem CII XML. Eingebaut ist operativ deutlich einfacher als nachträglich angeschraubt.

7. Ist das Rendering zustandslos? Wo landen meine Dokumente nach dem Rendern?

Zwei verwandte Fragen.

Zustandsloses Rendering bedeutet: Request kommt herein, PDF wird ausgegeben, nichts wird gespeichert. Persistenz steuern Sie selbst, etwa in S3, Ihrer Datenbank oder einem anderen System. Für compliance-lastige Workloads ist genau das meistens richtig, weil der Renderer nie Verwahrer Ihrer Daten wird.

Zustandsbehaftetes Rendering bedeutet: Der Anbieter speichert das PDF, oft auf seinem CDN, und gibt Ihnen eine signierte URL. Das ist bequem für lockere Abläufe wie “dem Kunden einen Link schicken”, aber problematisch für regulierte Workloads, weil ein Dritter eine Kopie jedes gerenderten Dokuments besitzt.

Fragen Sie:

“Ist Rendering standardmäßig zustandslos?”
“Wo wird das Dokument geografisch gespeichert, falls Sie es speichern?”
“Wie lange wird es aufbewahrt?”
“Bekomme ich eine schriftliche Zusicherung für zustandsloses Rendering im Compliance-Review?”

Wenn die Antwort ausweicht, wird Ihr Privacy- oder Legal-Team daraus in neun Monaten ein Thema machen.

8. Was passiert, wenn der Renderer ausfällt, und wie erfahre ich davon?

Jeder Renderer fällt manchmal aus. Die Fragen sind:

Wie zeigt sich der Fehler? Ein 500 mit Stack Trace? Ein 4xx mit strukturiertem Fehler? Ein leeres PDF?
Wie sieht die Retry-Policy aus? Ist sie idempotent? Werden fehlgeschlagene Renders berechnet?
Welche Instrumentierung stellt der Anbieter bereit? Statusseite? Webhooks für Incidents? p50/p99-Dashboards nach Region?
Gibt es einen synthetischen Probe? Überwacht der Anbieter selbst seinen öffentlichen Endpoint, oder wartet er darauf, dass Sie ein Ticket öffnen?

Ein schneller Test: Öffnen Sie jetzt die Statusseite des Anbieters. Wenn sie nicht existiert, nicht echtzeitnah ist oder nur “all systems operational” ohne Details zeigt, ist das die Transparenz, die Sie nach dem Kauf erwarten können.

Als Referenz: gPdf veröffentlicht /status mit synthetischen Probe-Daten und Cloudflare Analytics über die letzten 7 Tage.

Wie gPdf bei den acht Fragen abschneidet

Da dies unser Blog ist und Sie uns eine eigene Perspektive unterstellen werden, hier unsere ehrliche Scorecard:

#	Frage	gPdf-Antwort
1	Eingabeformat	JSON `DocumentRequest` (strukturierte Daten)
2	Cold Start	5 bis 20 ms (V8 isolate, kein Browser)
3	Kostenmodell	0/5/8/12 USD pro Monat; 0,00005 USD pro Seite Overage
4	Determinismus	Byte-identisch, garantiert innerhalb derselben Engine-Version
5	Fonts	NotoSans CJK plus lateinischer Fallback eingebettet
6	Compliance	PDF/A-1b/2b/3b/4 plus Factur-X / ZUGFeRD-Anhang integriert
7	Zustandslos	Ja, vertraglich: keine Dokumentenspeicherung irgendwo
8	Fehler und Sichtbarkeit	Öffentliche Statusseite mit 7-Tage-Trend; strukturierte 4xx/5xx; idempotent

Wo wir verlieren: Frage 1, wenn Ihr Input wirklich HTML ist und nicht refaktoriert werden kann, etwa nutzergenerierte Reports oder Legacy-Vorlagen. Dafür sind DocRaptor oder Prince die richtige Antwort.

Kurzfassung

Fragen Sie nicht: “Welche ist die beste PDF-API?” Stellen Sie die acht Fragen, bewerten Sie die Antworten und wählen Sie den Anbieter, der zu Ihrer tatsächlichen Last passt. Das Team, das eine Beschaffung an einen etwas günstigeren Wettbewerber verloren hat und neun Monate später von Frage 5 überrascht wurde, würde Ihnen dasselbe sagen.

Wenn Ihre Last zu dem passt, wofür gPdf gebaut ist, lässt sich das im Playground in 30 Sekunden prüfen. Wenn nicht, zeigen wir Ihnen gerne das passendere Werkzeug: meist DocRaptor für HTML-förmige Probleme, Prince für Self-Hosting oder Puppeteer, wenn Ihr Input wirklich aus beliebigen Webseiten besteht.