Öffnen Sie ein beliebiges geschäftskritisches PDF — eine Rechnung, ein Versandetikett, einen Monatsauszug — und sehen Sie sich die Dokumenteneigenschaften an (Cmd+D in macOS Preview, Ctrl+D in Adobe Reader, „Datei → Eigenschaften“ in den meisten Desktop-Viewern). Dann schauen Sie auf das Producer-Feld.

Wurde das PDF von einer SaaS-Plattform mit einem Headless-Browser erzeugt, sehen Sie häufig so etwas:

$ pdfinfo invoice.pdf
Title:           invoice-20260318.pdf
Subject:
Author:
Creator:         Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (...) Chrome/120.0.0.0
Producer:        Skia/PDF m120
Language:

Die Seite oben sieht aus wie die Marke des SaaS-Anbieters. Die Dateieigenschaften nennen eine Browser-Engine, die weder mit dem Anbieter noch mit dem Kunden, in dessen Namen er das Dokument ausliefert, etwas zu tun hat.

Diese Lücke ist das Thema dieses Beitrags.

Die Seite trägt die Marke, die Datei nicht

White-Label-PDF-Erzeugung ist eine wohlbekannte Anforderung für B2B-SaaS. Der Anbieter lässt den Kunden ein Logo hochladen, Markenfarben wählen, ein Template konfigurieren; die exportierten PDFs sehen visuell nach der Marke des Kunden aus, nicht nach der des Anbieters.

Die meisten Plattformen hören dort auf. Sie lösen die sichtbare Schicht und lassen die Schicht der Dateieigenschaften unangetastet. Das Ergebnis: ein Dokument, das auf jeder Seite „Acme Logistics“ sagt, sich aber als „Skia/PDF m120“ zu erkennen gibt, sobald jemand mit der rechten Maustaste → Eigenschaften öffnet.

Für einen einmaligen B2C-Download — einen privaten Kassenbon, ein Kinoticket — sind Dateieigenschaften überwiegend Kosmetik. Für ein B2B-Dokument oder einen regulierten B2C-Output (medizinische Berichte, Finanzaufstellungen, juristische Offenlegungen, regulierte Versicherungsformulare) sind die Dateieigenschaften Teil des Dokuments. Sie tauchen auf in:

Adobe Reader, Preview, Foxit, jedem Desktop-PDF-Viewer
Dokumenten-Management-Systemen (SharePoint, M-Files, NetSuite Files)
PDF-Previewern von Mailservern
Suchindizes (Spotlight, Outlook, interne DMS-Suche)
Archivsystemen (PDF/A-Langzeitarchivierung)
allem, was in einer Pipeline pdfinfo oder pdftk dump_data aufruft

Ein Dokument, dessen Seite „Acme“ sagt und dessen Producer-Feld „Chromium“ sagt, liest sich für solche Systeme als „von Chromium für jemanden namens Acme gerendert“ — nicht als „von Acme gerendert“. Im Blick von Einkauf und Compliance auf Enterprise-Seite registriert sich dieser Unterschied.

Warum das für den SaaS-Anbieter schlimmer ist als für direkte Nutzer

Wenn Sie ein PDF für sich selbst erzeugen, ist „Chromium“ im Producer-Feld nur Ihr Problem.

Sind Sie SaaS-Anbieter und Ihre Kunden erzeugen PDFs über Ihre Plattform, ist die Kette länger:

Sie haben den Rendering-Stack gewählt.
Ihr Kunde versendet das resultierende PDF an seinen Kunden.
Der endgültige Empfänger — ein Einkaufsteam, ein Spediteur, ein Finanzamt, eine Finanzabteilung — sieht ein Producer-Feld, das weder Sie noch Ihren Kunden nennt. Es nennt den vorgelagerten Renderer, den Sie zufällig einsetzen.

Auf der Seite die Marke Ihres Kunden; in der Datei ein unbekannter Tool-Name. Aus Empfängersicht wirkt das Dokument leicht schief, ohne dass man es benennen könnte. Aus Sicht Ihres Kunden wurde das White-Label-Versprechen nicht ganz eingelöst.

In diesem Teil investieren die meisten Plattformen zu wenig, weil die Reparatur von der Homepage aus nicht sichtbar ist. Aber der Kunde, der einmal pdfinfo auf den Output seiner „White-Label-PDF“-Funktion laufen lässt, wird es bemerken.

Wann das wirklich zubeißt

Das sind die Situationen, in denen das Producer-Feld als reales operatives Problem aufgetaucht ist — nicht hypothetisch:

Lieferanten-Sicherheitsfragebögen. Der Einkauf eines Unternehmens führt ein Vendor-Risk-Review durch und fragt: „Listen Sie jedes Drittanbieter-Tool auf, das in Dokumentenausgaben erscheint, die Sie an uns liefern.“ Das IT-Team des Kunden lässt pdfinfo auf ein Beispieldokument laufen und findet einen unbekannten Renderer-Namen. Niemand ist verärgert — aber der Name wird in die Liste der Unterauftragsverarbeiter aufgenommen, was wiederum ein Vendor-Management-Review und ein separates Set von Compliance-Prüfungen auslöst.
DMS-/Archiv-Suche. Das Dokumenten-Management-System des Kunden indexiert PDFs nach author. Wenn PDFs aus Ihrer Plattform ein leeres Author-Feld haben, kann das Compliance-Team des Kunden Monate später nicht mehr ohne Weiteres nach „Dokumenten dieses Anbieters“ filtern — am Ende werden manuelle Tags vergeben, die eigentlich nicht ihre Aufgabe wären.
Langzeitarchiv-Validierung. Ein PDF/A-Archivsystem markiert Dokumente, in denen Producer nicht zur erwarteten Anbieterliste passt. Das Compliance-Team muss „Skia/PDF m120“ und „wkhtmltopdf“ manuell als bekanntermaßen unbedenkliche Renderer freigeben — eine kleine, aber dauerhafte operative Last.
Marken-Konsistenzprüfungen. Manche Marketing-Teams in Unternehmen prüfen die Zuordnung ausgehender Dokumente im Rahmen der Markenführung. Ein Dokument, das einem Tool zugeordnet ist, von dem das Markenteam nie gehört hat, wird zu einem Prüffund.

Keine dieser Punkte ist ein kritischer Vorfall. Es sind Papierschnitte, die im Enterprise-Vertrieb, beim Onboarding von Kunden und im Betrieb Reibung erzeugen. Bei Tausenden Dokumenten pro Monat summiert es sich.

Was die Dateieigenschaften tatsächlich preisgeben

Die PDF-Spezifikation reserviert sechs Standard-Metadatenfelder, die nahezu jeder Viewer sichtbar macht:

Feld	Wofür es da ist	Was ein undichter Stack üblicherweise zeigt
`Title`	Dokumenttitel	Automatisch generierter Dateiname, oder leer
`Author`	Die Person oder Organisation, die das Dokument erstellt hat	Leer, oder der Name des Entwicklers
`Subject`	Kurzbeschreibung des Dokuments	Leer
`Creator`	Die Anwendung, die den Quellinhalt erzeugt hat	„Chromium“, „Mozilla/5.0…“, oder der interne Tool-Name des SaaS-Anbieters
`Producer`	Die Anwendung, die die PDF-Bytes erzeugt hat	„Skia/PDF m120“, „wkhtmltopdf 0.12.x“, „iText 7.x.x“
`Language`	BCP-47-Sprachtag	Leer, oder falsche Locale

Jedes davon ist ein kurzer String. Keins ist technisch schwer zu befüllen. Der Grund, warum sie standardmäßig durchsickern: Die Rendering-Bibliothek schreibt ihren eigenen Namen in Producer (korrekt — dafür ist das Feld da), und der meiste Anwendungscode setzt die anderen fünf nie.

Die Behebung besteht darin, sie zu setzen — bewusst, bei jedem Rendering, von der Anwendung aus, die weiß, wofür das Dokument bestimmt ist.

Wie „branded Metadata“ in der Praxis aussieht

Hier derselbe Metadatenblock, wie gPdf ihn erzeugt. Sechs Felder, alle vom Aufrufer überschreibbar:

{
  "settings": {
    "metadata": {
      "title":    "Invoice INV-2026-3401",
      "language": "en",
      "author":   "Acme Logistics, Inc.",
      "subject":  "Monthly invoice — 2026-03",
      "creator":  "Acme Billing Platform v7.2",
      "producer": "Acme Billing Platform"
    }
  }
}

Dasselbe pdfinfo gegen das resultierende PDF:

$ pdfinfo invoice.pdf
Title:           Invoice INV-2026-3401
Subject:         Monthly invoice — 2026-03
Author:          Acme Logistics, Inc.
Creator:         Acme Billing Platform v7.2
Producer:        Acme Billing Platform
Language:        en

Die Seite rendert als „Acme Logistics“ — und die Dateieigenschaften sagen ebenfalls „Acme Logistics“. Rechtsklick → Eigenschaften zeigt ein Dokument, das vollständig zu Acme gehört. Dass die Bytes von gPdf an der Edge in rund 4 ms erzeugt wurden, taucht an keiner Stelle auf, die der Empfänger einsehen kann.

Wollen Kunden nicht wissen, dass Sie gPdf einsetzen?

Diese Frage kommt oft genug, dass sie eine direkte Antwort verdient.

Ja — Ihre Kunden dürfen selbstverständlich wissen, dass Sie auf gPdf bauen. Das gehört zwischen Sie und sie, und es findet üblicherweise seinen Platz in Ihrem Engineering-Blog, im Changelog, in Sicherheitsarchitektur-Dokumenten oder in Ihrer Sub-Processor-Liste (in der gPdf auftaucht, wenn für Ihren AVV relevant).

Das Producer-Feld berührt diese Beziehung nicht. Es betrifft den Endempfänger des Dokuments Ihres Kunden — einen Einkaufssachbearbeiter, einen Spediteur-Disponenten, eine Bearbeiterin beim Finanzamt — der keinerlei Beziehung zu Ihrer Renderer-Wahl hat und keinen Grund, sich dafür zu interessieren. Für ihn ist „Skia/PDF m120“ im Eigenschaftendialog Rauschen; „Acme Billing Platform“ ist Signal.

Es ist auch nichts Unredliches daran. Die PDF-Spezifikation definiert Producer als „Name der Anwendung, die das ursprüngliche PDF erzeugt hat“. Wenn Sie auf gPdf einen PDF-Service aufbauen, hat Ihre Anwendung die Bytes erzeugt, die gPdf ausgeliefert hat. Das in Producer zu schreiben, ist akkurat. Die ehrliche Variante lautet:

gPdf ist die Rendering-Infrastruktur.
Ihre Plattform ist Producer.
Ihr Kunde ist Author.

Jede Schicht bekommt Anerkennung dort, wo die PDF-Spezifikation sie vorsieht.

Eine Fußnote zu nachgelagerten Pipelines

Wenn Ihr Output-PDF auf dem Weg zum Empfänger noch eine Nachbearbeitungsstufe durchläuft — Ghostscript ohne ausdrückliche Metadaten-Erhaltungs-Flags, ein Enterprise-DRM-/Wasserzeichen-Tool, ein „PDF-Optimierer“ —, schreibt ein Teil dieser Tools Producer leise auf den eigenen Namen um und macht die gerade gesetzten gebrandeten Metadaten zunichte. Testen Sie gegen Ihre tatsächliche Pipeline, nicht nur gegen die rohe gPdf-Antwort.

Eine Anmerkung dazu, was hier nicht steht

Der Genauigkeit halber: Die sechs Standardfelder oben sind, was gPdf heute bereitstellt. Das reicht, um die Dokumenteneigenschaften zu white-labeln — worum es in der Markenidentitäts-Erzählung geht.

Es reicht nicht, um beliebige Geschäftskontexte (Bestell-UUID, Lagercode, Template-Version) ins PDF zu legen, damit nachgelagerte Systeme sie lesen. Das ist eine separate, ergänzende Fähigkeit — XMP-Custom-Metadaten + beliebige Key-Value-Paare —, die die PDF-Spezifikation unterstützt und die wir als Roadmap-Punkt verfolgen. Wenn Sie es heute brauchen, lebt diese Art von ID-Daten meist verlässlicher in der Datenbank Ihrer Plattform, mit dem Dateinamen oder einem Hash als Schlüssel, als im PDF selbst. Metadaten dienen der Identität des Dokuments, nicht dazu, strukturierte Geschäftsdaten über PDFs als Transportlayer zu schieben.

Branded Metadata (heute) ≠ versteckter Geschäftsdaten-Fluss (separat). Lohnt sich, das in der eigenen Planung getrennt zu halten.

Das kleinstmögliche Upgrade

Wenn Sie bereits an /api/v1/pdf/render POSTen und Ihr aktueller Call kein settings.metadata enthält, ist die kleinste Verbesserung drei zusätzliche Zeilen im JSON, das Sie ohnehin senden:

 {
   "pages": [...],
   "settings": {
+    "metadata": {
+      "author":   "Your customer's organisation",
+      "producer": "Your platform"
+    }
   }
 }

Zwei Felder, ein neuer Key. In Sekunden mit pdfinfo verifizierbar. Sobald das steht, befüllen Sie title, language, subject und creator, wenn Sie Zeit haben.

Wo das in der gPdf-API landet

Sechs Zeilen unter settings.metadata. Per-Token-Policies können diese Felder zusätzlich strippen oder mit Defaults belegen, sodass ein Multi-Tenant-SaaS erzwingen kann, dass jedes PDF, das seine Kunden erzeugen, korrekt zugeordnet ist — ohne jedem API-Aufrufer vertrauen zu müssen.

§4.14.2 Metadata in der API-Referenz — die Referenz Feld für Feld.
Felderweise vertiefend — wann title / language / author / subject / creator / producer jeweils zählen, was Leser tatsächlich damit tun und wie Sie verifizieren, was ausgeliefert wurde.

Die sichtbare Seite ist die halbe Marke. Die Dateieigenschaften sind die andere Hälfte. Wenn Ihre Plattform PDFs im Namen von Kunden ausliefert, sollten beide Hälften deren Namen tragen.