Open een willekeurige bedrijfskritische PDF — een factuur, een verzendlabel, een maandelijks overzicht — en bekijk de documenteigenschappen (Cmd+D in Preview op macOS, Ctrl+D in Adobe Reader, “Bestand → Eigenschappen” in de meeste desktopviewers). Kijk vervolgens naar het veld Producer.

Als de PDF is gegenereerd door een SaaS-platform via een headless browser, ziet u vaak iets als:

$ 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:

De pagina hierboven oogt als het merk van de SaaS-leverancier. De bestandseigenschappen noemen een browser-engine die niets te maken heeft met die leverancier — of met de klant namens wie de SaaS het document verstuurt.

Die kloof is waar deze post over gaat.

De pagina is gebrand, het bestand niet

White-label PDF-generatie is een goed begrepen vereiste voor B2B SaaS. De leverancier laat de klant een logo uploaden, merkkleuren kiezen, een template configureren; geëxporteerde PDF’s lijken visueel op het merk van de klant, niet op dat van de leverancier.

De meeste platforms stoppen daar. Ze lossen de zichtbare laag op en laten de bestandseigenschappenlaag met rust. Resultaat: een document dat op elke pagina “Acme Logistics” zegt, maar zich identificeert als “Skia/PDF m120” zodra iemand met de rechtermuisknop → Eigenschappen klikt.

Voor een eenmalige B2C-download — een persoonlijk bonnetje, een bioscoopkaartje — zijn bestandseigenschappen vooral cosmetisch. Voor een B2B-document, of elke gereguleerde B2C-output (medische rapporten, financiële overzichten, juridische mededelingen, gereguleerde verzekeringsformulieren), maken de bestandseigenschappen deel uit van het document. Ze duiken op in:

Adobe Reader, Preview, Foxit, elke desktop PDF-viewer
Documentbeheersystemen (SharePoint, M-Files, NetSuite Files)
PDF-previewers van mailservers
Zoekindexen (Spotlight, Outlook, interne DMS-zoekfunctie)
Archiefsystemen (PDF/A voor langetermijnbewaring)
Alles wat pdfinfo of pdftk dump_data in een pipeline aanroept

Een document waarvan de pagina “Acme” zegt en het Producer-veld “Chromium” zegt, leest voor die systemen als “gerenderd door Chromium voor iemand die Acme heet” — en niet als “gerenderd door Acme”. Voor enterprise-inkoop en naleving valt dat onderscheid op.

Waarom dit erger is voor de SaaS-leverancier dan voor directe gebruikers

Als u een PDF voor uzelf genereert, is “Chromium” in het Producer-veld alleen uw probleem.

Als u een SaaS-leverancier bent en uw klanten PDF’s genereren via uw platform, is de keten langer:

U koos de renderstack.
Uw klant levert de resulterende PDF aan zijn klant.
De uiteindelijke ontvanger — een inkoopteam, een vervoerder, een belastingautoriteit, een financiële afdeling — ziet een Producer-veld dat noch u noch uw klant noemt. Het noemt de upstream renderengine die u toevallig gebruikt.

Het merk van uw klant op de pagina; een onbekende toolnaam in het bestand. Vanuit het perspectief van de ontvanger oogt het document een tikje vreemd zonder dat zij dat helemaal kunnen benoemen. Vanuit het perspectief van uw klant is de white-labelbelofte niet helemaal nagekomen.

Dit is het deel waarin de meeste platforms te weinig investeren, omdat de oplossing niet zichtbaar is vanaf de homepage. Maar de klant die één enkele pdfinfo op de output van uw white-label PDF-functie loslaat, zal het opmerken.

Wanneer dit echt bijt

Dit zijn de situaties waarin het Producer-veld als een reëel operationeel probleem boven kwam drijven, niet als hypothese:

Beveiligingsvragenlijsten van leveranciers. Enterprise-inkoop voert een leveranciersrisicoreview uit en vraagt: “som elke externe tool op die verschijnt in documenten die u aan ons levert.” Het IT-team van de klant draait pdfinfo op een voorbeelddocument en vindt een onbekende renderenginenaam. Niemand wordt boos — maar het wordt toegevoegd aan de lijst met subverwerkers, wat vervolgens een leveranciersbeheerreview en een aparte set nalevingschecks oplevert.
DMS / archiefzoekfunctie. Het documentbeheersysteem van de klant indexeert PDF’s op author. Wanneer PDF’s van uw platform een leeg Author-veld hebben, kan het nalevingsteam van de klant maanden later niet eenvoudig filteren op “documenten van deze leverancier” — ze gaan handmatige tags toevoegen, wat niet zou moeten hoeven.
Validatie van langetermijnarchieven. Een PDF/A-archiefsysteem markeert documenten waarvan Producer niet matcht met de verwachte leverancierslijst. Het nalevingsteam moet handmatig “Skia/PDF m120” en “wkhtmltopdf” op de allowlist zetten als bekende goede renderengines — een kleine, maar doorlopende operationele last.
Audits van merkconsistentie. Sommige enterprise marketingteams auditen toeschrijving van uitgaande documenten als onderdeel van merkgovernance. Een document toegeschreven aan een tool waarvan het merkteam nog nooit heeft gehoord, wordt een bevinding.

Geen van deze is een kritisch incident. Het zijn vinnige steekjes die wrijving toevoegen aan enterprise sales, leveranciers-onboarding en operations. Ze stapelen zich op over duizenden documenten per maand.

Wat de bestandseigenschappen werkelijk blootleggen

De PDF-specificatie reserveert zes standaard metadatavelden die vrijwel elke viewer naar boven brengt:

Veld	Waarvoor het dient	Wat een lekkende stack meestal toont
`Title`	Documenttitel	Automatisch gegenereerde bestandsnaam, of leeg
`Author`	De persoon of organisatie die het document heeft gemaakt	Leeg, of de naam van de ontwikkelaar
`Subject`	Korte beschrijving van het document	Leeg
`Creator`	De applicatie die de broninhoud heeft geproduceerd	“Chromium”, “Mozilla/5.0…” of de interne toolnaam van de SaaS-leverancier
`Producer`	De applicatie die de PDF-bytes heeft geproduceerd	“Skia/PDF m120”, “wkhtmltopdf 0.12.x”, “iText 7.x.x”
`Language`	BCP-47 taaltag	Leeg, of verkeerde locale

Elk van deze is een korte string. Geen daarvan is technisch lastig in te vullen. De reden dat ze standaard lekken, is dat de renderbibliotheek haar eigen naam in Producer schrijft (terecht — daar is het veld voor), en dat de meeste applicatiecode de andere vijf nooit instelt.

De oplossing is ze te zetten — bewust, bij elke render, vanuit de applicatie die weet waarvoor het document dient.

Hoe “gebrande metadata” er in de praktijk uitziet

Hier is hetzelfde metadatablok zoals gPdf het produceert. Zes velden, allemaal overschrijfbaar door de aanroeper:

{
  "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"
    }
  }
}

Dezelfde pdfinfo op de resulterende 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

De pagina rendert als “Acme Logistics” — en de bestandseigenschappen zeggen ook “Acme Logistics”. Rechtermuisknop → Eigenschappen toont een document dat volledig van Acme is. Het feit dat de bytes door gPdf aan de edge in ~4 ms zijn geproduceerd, duikt nergens op waar de ontvanger kijkt.

Willen klanten dan niet weten dat u gPdf gebruikt?

Deze vraag komt vaak genoeg voorbij om direct beantwoord te worden.

Ja — uw klanten mogen absoluut weten dat u op gPdf bouwt. Dat is tussen u en hen, en hoort meestal thuis in uw engineering blog, uw changelog, uw beveiligingsarchitectuurdocumenten of uw sub-processor lijst (waarop gPdf voorkomt als dat relevant is voor uw DPA).

Het Producer-veld gaat niet over die relatie. Het gaat over de uiteindelijke ontvanger van het document van uw klant — een inkoopmedewerker, een transportplanner, een medewerker van een belastingautoriteit — die geen enkele relatie heeft met uw keuze van renderengine en geen reden heeft om zich daarvoor te interesseren. Voor zo’n persoon is “Skia/PDF m120” in het dialoogvenster Eigenschappen ruis; “Acme Billing Platform” is signaal.

Er is ook niets oneerlijks aan. De PDF-spec definieert Producer als “de naam van de applicatie die de oorspronkelijke PDF heeft geproduceerd”. Als u een PDF-dienst bovenop gPdf bouwt, heeft uw applicatie de bytes geproduceerd die gPdf heeft uitgeleverd. Dat in Producer zetten is correct. De eerlijke versie is:

gPdf is de render-infrastructuur.
Uw platform is de producer.
Uw klant is de author.

Elke laag krijgt de credit die de PDF-spec bedoelt.

Een voetnoot over downstream pipelines

Als uw output-PDF een naverwerkingsfase passeert voordat deze de ontvanger bereikt — Ghostscript zonder expliciete metadata-behoudvlaggen, een enterprise DRM/watermark-tool, een “PDF-optimalisator” — zullen sommige van die tools Producer stilletjes herschrijven naar hun eigen naam en de gebrande metadata die u zojuist instelde tenietdoen. Test tegen uw werkelijke productieketen, niet alleen tegen de ruwe gPdf-respons.

Een noot over wat hier niet staat

Om accuraat te blijven: de zes standaardvelden hierboven zijn wat gPdf vandaag blootlegt. Dat is genoeg om de documenteigenschappen white-label te maken — waar het verhaal over merkidentiteit over gaat.

Het is niet genoeg om willekeurige bedrijfscontext (order-UUID, magazijncode, templateversie) in de PDF te verstoppen zodat systemen verderop in de keten die kunnen lezen. Dat is een aparte, aanvullende mogelijkheid: XMP custom metadata plus willekeurige key-value pairs, ondersteund door de PDF-specificatie en gevolgd als roadmap-item. Als u het vandaag nodig heeft, leven ID-achtige data doorgaans betrouwbaarder in de database van uw eigen platform, gekoppeld aan de bestandsnaam of een hash van de PDF, dan binnen de PDF zelf. Metadata zijn voor de identiteit van het document, niet voor het transporteren van gestructureerde businessdata via PDF’s als transportlaag.

Gebrande metadata (vandaag) ≠ verborgen businessdata-stroom (apart). Het is de moeite waard om die in uw eigen planning gescheiden te houden.

De kleinst mogelijke upgrade

Als u al een POST doet naar /api/v1/pdf/render en uw huidige aanroep heeft geen settings.metadata, is de kleinste verbetering drie regels toegevoegd aan de JSON die u al verstuurt:

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

Twee velden, één nieuwe sleutel. Verifieerbaar met pdfinfo binnen seconden. Zodra deze landen, vult u title, language, subject en creator in wanneer u tijd heeft.

Waar dit landt in de gPdf API

Zes regels binnen settings.metadata. Policies per token kunnen deze velden ook strippen of een default geven, zodat een multi-tenant SaaS kan afdwingen dat elke PDF die zijn klanten genereren correct wordt toegeschreven, zonder te hoeven vertrouwen dat elke API-aanroeper ze instelt.

§4.14.2 Metadata in de API-referentie — de referentie veld voor veld.
Veld-voor-veld diepteduik — wanneer elk van title / language / author / subject / creator / producer ertoe doet, wat lezers er daadwerkelijk mee doen en hoe te verifiëren wat u verzonden heeft.

De zichtbare pagina is de helft van het merk. De bestandseigenschappen zijn de andere helft. Als uw platform PDF’s namens klanten verstuurt, zouden beide helften hun naam moeten dragen.