What is the difference between Creator and Producer in PDF metadata?
Creator and Producer are two text fields in a PDF’s document information that name the software involved in making the file. Creator is the application the content was authored in, such as Word, InDesign or a web browser. Producer is the software that actually wrote the PDF file. When one program does both jobs the two fields are often similar or identical; when two programs are involved they differ, and that is ordinary.
The two fields in plain terms
Think of a printed book. The Creator is the author’s word processor; the Producer is the printing press. A PDF stores both as short text labels, normally something like a product name and a version number. They sit in the file’s document information dictionary, under the keys Creator and Producer, and many files repeat them in the XMP metadata block as CreatorTool and Producer. Neither field is required, and neither is checked by the PDF format itself: whatever the software writes is what you see.
Typical examples
- An Office app exporting to PDF. Saving or exporting from Word, Excel or LibreOffice usually writes the same application into both fields, often with a version number, because the app is also the PDF writer.
- A print-to-PDF driver. The document is first ‘printed’ by the authoring app to a virtual printer. The Creator then tends to name the printer driver or the originating app, and the Producer names the PDF engine behind the driver, so the two differ.
- A web browser. Printing a page to PDF from Chrome, Edge or Firefox typically gives a browser or rendering-engine name in one or both fields rather than the website that served the page.
- A scanner or phone app. The Creator may be the scanning app or device, and the Producer the library that packaged the images into a PDF.
- An online converter or PDF tool. These typically record their own engine as Producer, and may leave Creator empty or carry over the original application.
Exact strings vary by product, platform and version, so treat these as patterns rather than fixed values.
How to read them
- Same value in both. One program authored and wrote the file. Very common for direct exports.
- Different values. A pipeline of at least two programs, such as an authoring app plus a driver or converter. Also very common, and fully legitimate.
- One field empty. Some software never writes one of them, and some tools remove them when saving. An empty field on its own proves nothing either way.
- A version number. It tells you roughly which release of the software wrote the file, which is useful context when a document claims to come from a particular system or date.
What they can and cannot tell you
Creator and Producer describe the toolchain that wrote the file, and that is all. They can help you judge whether a document looks like it came from the kind of software you would expect: a payslip exported by a payroll system, an invoice from an accounting package, a certificate generated by a registry.
They do not prove that a document is genuine, and they do not prove that it was altered. The fields are plain text with no cryptographic protection, they can be missing, and an unchanged original and a later edited copy can carry the same or different values for entirely innocent reasons. A file that was simply re-saved or merged with another document will often show a different Producer without any change to its content. Read the pair as one clue among many, alongside the creation and modification dates, the document’s structure and its visible content, never as a verdict on its own.
Common misreadings
- ‘Different values mean it was edited.’ No. Print drivers and converters produce different values in an untouched file.
- ‘A famous producer means it is genuine.’ No. Anyone can run the same software, and the text can be rewritten.
- ‘Empty means hidden.’ Usually it means the software never wrote the field.
- ‘Creator is the person.’ It is software. The person, if recorded, is in Author.
How HTPBE? treats the pair
HTPBE? reads Creator and Producer as claims about origin, not as facts. When the evidence shows the stated origin does not hold up, the result names it, for example HTPBE_TOOL_VS_STRUCTURE_MISMATCH or HTPBE_IDENTITY_OVERWRITTEN. A plausible-looking pair is not taken at face value. Long values are shortened for display; the result flags when that happened (creator_truncated, producer_truncated in the API).
When this does not apply
If the Info dictionary and the XMP block name different tools, or a file carries neither, there is no single pair to read. Scans and photos name the capture app, not an authoring system.
How to look at them yourself
In most PDF viewers, open Document Properties: the application and PDF producer lines are usually shown there. The free PDF metadata viewer displays Creator, Producer and the other document properties of any PDF in your report, and the PDF metadata FAQ covers the rest of the fields.
To go beyond reading labels and analyse the file itself for signs of modification, see PDF tamper detection, or use the HTPBE? API to check documents programmatically; pricing lists the plans and pay-per-check credits.
Related questions
← Previous
Can I use the PDF checker for legal documents?
Next →
Does the PDF checker read my document content?
Related questions
Keep reading
3 answers
How Detection Works
An incremental update is how a PDF records a change by appending it to the end of the file instead of rewriting it, so one file can hold several versions. Signing, form filling and annotating also use it, so presence alone is not an accusation.
Yes. No detection method is complete: content that was false from the start, changes that leave no structural trace, and unreadable or locked files fall outside what HTPBE? can flag. It returns Inconclusive instead of Intact where it cannot tell.
Privacy, Data & Limits
No. HTPBE? analyses the structure of the file – metadata, structure, signatures and embedded content – not what the document says. It does no OCR and cannot tell you whether amounts, names or dates inside are correct.