PDFMonkey ist ein starkes HTML-Vorlagenprodukt
PDFMonkey ist kein schwacher Wettbewerber. Es ist ein ausgereiftes gehostetes Produkt für Teams, die PDFs aus Vorlagen, dynamischen Daten und Automatisierungswerkzeugen erstellen wollen. Die aktuelle Dokumentation beschreibt zwei Vorlagenpfade: einen visuellen Builder und Code Templates in HTML, CSS und Liquid. Dazu kommen REST API, Webhooks, No-Code-Integrationen, Dokumentenaufbewahrung, signierte Download-URLs und passwortgeschützte PDFs.
Damit passt PDFMonkey gut zu Teams, die in HTML-Vorlagen oder No-Code-Abläufen denken. Die schärfere Frage lautet, ob Ihre Produktions-PDFs HTML-Dokumente sein sollen, die Chromium rendert, oder strukturierte Geschäftsdokumente aus einem PDF-nativen JSON-Vertrag.
Entscheidung in 30 Sekunden
- Bestehende HTML/CSS-Quelle, Liquid-Vorlagen oder No-Code-Automatisierung? Wählen Sie PDFMonkey.
- Sie brauchen einen Dashboard-Eintrag und eine signierte Download-URL für jedes generierte Dokument? Wählen Sie PDFMonkey.
- Sie erzeugen strukturierte Rechnungen, Versandlabels, Belege, Kontoauszüge, Tickets oder E-Invoices in hohem Volumen? Wählen Sie gPdf.
- Sie brauchen direkte PDF-Bytes aus einem API-Aufruf ohne Dokumentenpersistenz als Standardverhalten? Wählen Sie gPdf.
- Sie brauchen PDF/A, Factur-X/ZUGFeRD, Vektor-Barcode-Primitives oder Dokumentberechtigungen? Wählen Sie gPdf.
- Sie brauchen Hosting in AWS EU Paris als gehostete Standardgrenze? Wählen Sie PDFMonkey, außer eine private gPdf-Bereitstellung ist im Scope.
Die echte Produktgrenze: Dokumenten-App vs PDF-Infrastruktur
PDFMonkey verhält sich wie eine Dokumentengenerierungs-App mit API. Sie erstellen Vorlagen, erzeugen Dokumentdatensätze, lassen den Service rendern und holen nach erfolgreicher Generierung eine signierte URL ab. Das ist nützlich, wenn der Dokumentlebenszyklus zählt: Dashboard-Prüfung, Aufbewahrung, manuelle Löschung, Share Links und Übergabe an Automationsplattformen.
gPdf verhält sich wie PDF-Infrastruktur. JSON Render und Template Render geben bei Erfolg PDF-Bytes direkt zurück. Das Standard-Sicherheitsmodell ist für Dokumentinhalte zustandslos: Das Anfrage-JSON liegt nur während des Renders im Speicher, das ausgegebene PDF wird zurückgestreamt, und weder Anfragekörper noch PDF-Bytes werden standardmäßig gespeichert.
Beide Modelle sind legitim. Sie lösen unterschiedliche operative Probleme.
HTML/CSS ist PDFMonkeys natürlicher Vorteil
PDFMonkeys Code Templates nutzen HTML, CSS und Liquid. Genau das kennen viele Teams bereits. Wenn Ihre Rechnungsvorlage eine Webansicht ist, Ihre E-Mail-Vorlage bereits HTML ist oder Ihr Betriebsteam Tailwind-Klassen und Webfonts wiederverwenden möchte, ist PDFMonkey naheliegend.
Auch der visuelle Builder ist für nichttechnische Nutzer hilfreich. Die offiziellen Dokumente beschreiben ihn als visuelles Drag-and-Drop mit niedrigerer Lernkurve als Code Templates, und sowohl Builder als auch Code Templates rendern über Chromium. Für geradlinige Business-Dokumente mit Headern, Text, Bildern, Tabellen und wiederholten Abschnitten ist das eine praktische Erstellungserfahrung.
HTML-Rendering ist auch wirklich besser, wenn das PDF einer Webseite nah ist: Marketing-Dokumente mit reichhaltigem CSS, Berichte mit bestehenden Frontend-Komponenten, Dokumente mit JavaScript-generierten Charts, stark CSS-Framework-geprägte Vorlagen oder mehrseitige HTML-Layouts, bei denen das Browser-Modell bereits die maßgebliche Quelle ist. gPdf versucht nicht, diesen Ablauf zu ersetzen.
Der Trade-off: Builder-Vorlagen und Code Templates sind separate Vorlagentypen. PDFMonkeys Dokumente sagen, dass sie nicht ineinander konvertiert werden können. gPdf geht anders vor: Visueller Editor und API teilen dieselbe JSON-Basis. Die Vorlage ist nicht an einer Stelle HTML und anderswo eine andere Vorlagenrepräsentation; sie ist derselbe strukturierte Dokumentvertrag, visuell betrachtet oder durch die API gesendet.
Bei strukturierten Dokumenten zieht gPdf vorbei
Rechnungen, Labels, Belege, Kontoauszüge, Tickets, Zertifikate und E-Invoice-PDFs sind meist keine beliebigen Webseiten. Sie bestehen aus strukturierten Daten, exakten Positionen, Seitengrößen, Summen, Barcodes, Metadaten und Compliance-Regeln.
Für diesen Workload ist das JSON-native Modell von gPdf direkter. Statt für jedes Dokument eine vollständige HTML-Seite zusammenzubauen, sendet der Aufrufer template_id + data an /api/v1/template-render oder einen vollständigen DocumentRequest an /api/v1/pdf/render. Die PDF-Schicht übernimmt Seitengeometrie, Text, Tabellen, Bilder, Barcodes, Metadaten, Sicherheitsregeln und Ausgabe.
Das zählt noch stärker in KI-gestützten Abläufen. Ein KI-Agent kann schema-gültiges JSON zuverlässiger erzeugen und reparieren, als vorherzusagen, ob eine im Browser gerenderte HTML-Seite korrekt paginiert, gedruckt oder per Barcode gescannt wird.
Kosten, ehrlich betrachtet
PDFMonkeys öffentliche Preise wurden am 2026-06-04 geprüft. Die öffentlichen Pläne reichen von Free bis Premium. Free enthält 20 Dokumente pro Monat. Starter kostet 5 EUR/Monat für 300 Dokumente. Pro kostet 15 EUR/Monat für 3.000 Dokumente. Pro+ kostet 60 EUR/Monat für 5.000 Dokumente. Premium kostet 300 EUR/Monat für 60.000 Dokumente. Pay-as-you-go-Mehrverbrauch ist auf Pro+ und Premium verfügbar; Premium-Mehrverbrauch ist mit 0,005 EUR je zusätzlichem Dokument gelistet.
Bei 100.000 einseitigen Dokumenten pro Monat sind das nach Premium-Listenpreis vor MwSt. grob 500 EUR: 300 EUR für 60.000 Dokumente plus 40.000 zusätzliche Dokumente zu je 0,005 EUR.
gPdf Basic kostet 5 USD/Monat für 100.000 Seiten. Das ist der Kernunterschied: PDFMonkey bepreist eine Dokumentengenerierungs-Anwendung; gPdf bepreist PDF-Erzeugung wie Infrastruktur.
Für mehrseitige Dokumente müssen Sie neu rechnen. Wenn Ihr durchschnittliches PDF N Seiten hat, ist gPdf-Nutzung ungefähr documents × N Seiten, während PDFMonkeys öffentliches Modell Dokumente zählt. Einseitige Rechnungen, Labels, Tickets und Belege machen den gPdf-Preisvergleich am stärksten; lange Berichte oder Kontoauszüge brauchen Workload-spezifische Mathematik.
Bei niedrigem Volumen können beide so günstig sein, dass Architektur wichtiger ist als Preis. Bei Hochvolumen-Labels, Belegen, Rechnungen und Kontoauszügen wird das Preismodell zur Architekturentscheidung.
Datenschutz und Aufbewahrung sind nicht dasselbe
PDFMonkeys Dokumente sind klar: Der Service speichert payload und meta bis zur Dokumentlöschung, speichert generierte Dateien in privatem S3 und nutzt kurzlebige vorsignierte Download-URLs. Die Sicherheitsdokumentation sagt, dass Daten bei der Übertragung verschlüsselt sind, dynamische Daten in verschlüsselten Datenbankspalten liegen, generierte Dateien in privaten S3-Buckets liegen und die Infrastruktur auf AWS in der EU-Region Paris gehostet wird.
Das ist ein glaubwürdiges gehostetes Dokumentlebenszyklus-Modell. Es ist aber nicht dasselbe wie ein zustandsloser Renderpfad.
gPdfs Standard-Renderpfad persistiert keine Dokumentinhalte. Wenn Ihr System nur die generierten Bytes braucht und Speicher, Audit-Logs und Auslieferung bereits besitzt, ist das eine sauberere Grenze. Wenn Ihr Team will, dass das PDF-Generierungsprodukt generierte Dokumente behält, Download-Links bereitstellt und Nutzer sie später prüfen oder löschen können, kann PDFMonkeys Modell die bessere Produktpassung sein.
Ausfallmodus und Latenz
Beide Produkte sind gehostete APIs, also führen beide eine Anbieter-Abhängigkeit ein. Der Unterschied ist die Ausführungsform.
PDFMonkeys API erstellt ein Dokument und gibt ein Dokumentobjekt zurück. Produktionscode prüft den Status normalerweise per Polling oder nutzt einen Webhook, um zu wissen, wann das Dokument bereit ist. Dieses Design passt zu asynchronen Abläufen und dashboardzentrierten Prozessen.
gPdfs JSON Render und Template Render geben bei Erfolg direkt application/pdf zurück. Das ist besser für synchrone Abläufe wie “Nutzer klickt Rechnung herunterladen”, für Versandlabel-Erzeugung in Lagerprozessen und für Backends, die einen einfachen Request-Response-Vertrag wollen.
Passwörter, Berechtigungen und Compliance
PDFMonkey hat eine starke einfache Passwort-Story: Übergeben Sie _password in Document Metadata, und das generierte PDF wird mit AES-256 verschlüsselt. Die Dokumente sagen, dass das mit allen Vorlagen, Integrationen und Tarifen funktioniert.
gPdfs Sicherheitsmodell ist stärker policy-orientiert. Pro unterstützt AES-128 Open-Password-Ausgabe. Enterprise Policy unterstützt AES-256, Owner Passwords und Dokumentberechtigungs-Bits wie print, modify, copy, annotate, fill forms, assemble und high-quality print. Das gibt Einkaufs- und Compliance-Teams granularere Kontrollen, ist aber bewusst tarifgebunden und gegenseitig ausgeschlossen mit PDF/A- und E-Invoice-Modi.
Für Archivierung und E-Invoice-Abläufe hat gPdf den klareren produktisierten Pfad: PDF/A-Profile und eine dedizierte Factur-X/ZUGFeRD PDF/A-3-Route. In PDFMonkeys aktuellen öffentlichen Dokumenten wurde während dieses Reviews kein vergleichbarer öffentlicher PDF/A- oder Factur-X/ZUGFeRD-Renderpfad gefunden.
Migrationsform
Von PDFMonkey zu gPdf zu wechseln ist keine Zeile-für-Zeile-Konvertierung von Liquid nach JSON. Die bessere Migration trennt stabile Layoutteile von variablen Geschäftsdaten.
- // Before: create a PDFMonkey document and poll or wait for a webhook
- const response = await fetch("https://api.pdfmonkey.io/api/v1/documents", {
- method: "POST",
- headers: {
- Authorization: "Bearer PDFMONKEY_SECRET_KEY",
- "Content-Type": "application/json"
- },
- body: JSON.stringify({
- document: {
- document_template_id: "YOUR-TEMPLATE-ID",
- status: "pending",
- payload: {
- invoice_number: "INV-2026-001",
- total: "$240.00"
- }
- }
- })
- });
- const document = await response.json();
- // Later: poll document_cards or receive a webhook, then download the signed URL.
+ // After: render through a shared gPdf template and receive PDF bytes
+ const response = await fetch("https://api.gpdf.com/api/v1/template-render", {
+ method: "POST",
+ headers: {
+ Authorization: `Bearer ${process.env.GPDF_TOKEN}`,
+ "Content-Type": "application/json"
+ },
+ body: JSON.stringify({
+ template_id: "invoice-v2",
+ data: [{
+ invoice_number: "INV-2026-001",
+ total: "$240.00"
+ }]
+ })
+ });
+ const pdfBytes = await response.arrayBuffer();Die wichtige Änderung ist nicht die Syntax. Es ist der Produktvertrag: weg von einem gespeicherten Dokumentlebenszyklus, hin zu einem direkten PDF-Infrastrukturaufruf.
Finale Wahl
Wählen Sie PDFMonkey, wenn Ihr Team bereits HTML/CSS-Vorlagen besitzt und sie behalten will. Wählen Sie es, wenn No-Code-Automatisierung der wichtigste Arbeitsablauf des Käufers ist. Wählen Sie es, wenn Dokumentenaufbewahrung, Dashboard-Prüfung, signierte Download-URLs oder Hosting in AWS EU Paris zentrale Anforderungen sind. Auch wenn das Unternehmen eine freundliche Dokumentengenerierungs-App mit API will statt einer Low-Level-Infrastrukturschicht, passt PDFMonkey.
Wählen Sie gPdf, wenn das PDF aus strukturierten Backend-Daten generiert wird und der Aufrufer vorhersehbaren Output ohne Browser-Rendering-Modell will. Versandlabels, Rechnungen, Belege, Lagerdokumente, Kontoauszüge, Tickets, Zertifikate und E-Invoice-PDFs stehen im Zentrum des Produkts.
Quellenhinweis
PDFMonkey-Preise und -Dokumente wurden am 2026-06-04 gegen die offizielle pricing page, Builder vs Code Templates, API PDF generation, security measures, data storage and retention und password protection geprüft. Wettbewerberpreise und Feature-Seiten können sich ändern; Einkaufsteams sollten PDFMonkeys offizielle Seiten vor einer Kaufentscheidung erneut prüfen.
Verwandte Szenarien für PDF-Erzeugung
Die nächsten sinnvollen Seiten hängen von der Dokumentfamilie ab. Für strukturierte Daten-zu-PDF-Anwendungsfälle starten Sie mit JSON-to-PDF API und Template PDF API. Für konkrete Anwendungsfälle vergleichen Sie Rechnungs-PDF-Erzeugung, Versandlabels und Batch-PDF-Erzeugung. Für Compliance-lastige Dokumente lesen Sie PDF/A API, Factur-X API und ZUGFeRD API.
FAQ
Ist gPdf eine PDFMonkey-Alternative?
Ja, wenn das Ziel strukturierte PDF-Erzeugung über eine API ist. PDFMonkey bleibt eine starke Wahl, wenn HTML/CSS-Vorlagen, Builder-Vorlagen, No-Code-Integrationen, Dokumentenaufbewahrung und signierte Download-URLs zum gewünschten Ablauf gehören.
Ist PDFMonkey besser für HTML-Vorlagen?
Ja. Wenn Ihre maßgebliche Quelle HTML/CSS ist, sind PDFMonkeys Code Templates die natürlichere Passung. gPdf ist bewusst JSON-nativ und versucht nicht, ein beliebiger HTML-to-PDF-Konverter zu sein.
Was ist günstiger für 100.000 PDFs pro Monat?
Für 100.000 einseitige PDFs kostet gPdf Basic nach öffentlichen Listenpreisen, geprüft am 2026-06-04, 5 USD/Monat für 100.000 Seiten. PDFMonkey Premium kostet 300 EUR/Monat für 60.000 Dokumente, mit zusätzlichen Premium-Dokumenten zu 0,005 EUR pro Stück, wenn Pay-as-you-go aktiviert ist. Wenn Ihre Dokumente im Schnitt mehr als eine Seite haben, rechnen Sie gPdf nach Seitenzahl und PDFMonkey nach Dokumentzahl neu.
Speichert PDFMonkey Dokumentdaten?
Ja. PDFMonkeys Dokumente sagen, dass payload und meta bis zur Dokumentlöschung gespeichert werden und generierte Dateien bis Löschung oder TTL-Ablauf in privatem S3 liegen. Das unterstützt Dashboard- und Download-Link-Abläufe. gPdfs Standard-Renderpfad persistiert keine Anfragekörper oder PDF-Bytes.
Unterstützt gPdf No-Code-Integrationen wie PDFMonkey?
Nicht als dieselbe Produktoberfläche. PDFMonkey hat No-Code-Integrationen wie Zapier, Make, n8n, Bubble und Workato. gPdf ist primär ein API- und Studio-Ablauf für Teams, die PDF-Erzeugung als Infrastruktur wollen.
Welches Produkt sollte ich für E-Invoices nutzen?
Nutzen Sie gPdf, wenn Sie unterstütztes Factur-X oder ZUGFeRD PDF/A-3 Packaging aus einer API brauchen. Nutzen Sie PDFMonkey, wenn Ihr E-Invoice-Bedarf nur ein visuelles Rechnungs-PDF aus HTML ist und Sie gesetzliches XML, Archivierung und Clearance anderswo handhaben.