← All posts

What “created with” and “produced by” reveal about your PDF

You opened a PDF's properties to check something else — the page count, maybe, or whether it was encrypted — and near the bottom there were two lines you had never looked at before. Created with: Microsoft® Word for Microsoft 365. Produced by: Microsoft® Word for Microsoft 365. The same thing, twice, which makes them look like a bug.

Or they said something you do not recognise at all. Skia/PDF m119. macOS Version 14.5 (Build 23F79) Quartz PDFContext. GPL Ghostscript 10.02.1. Nobody in your organisation has ever typed any of that.

Nobody typed it anywhere. These two fields are written by software, about software, and they are the only part of a PDF's properties that is filled in honestly by default. Here is what each one holds, why they so often agree, what it means when they do not, and when it is worth taking them out.

What the two fields actually say

The PDF specification defines them narrowly, and the narrow definition is the whole answer to the question people keep asking on forums:

So the pair is not two names for one program. It is a record of a route: what the thing was, and what carried it across into PDF. Read them together and they describe a journey.

They look identical whenever one program does both jobs. Word's own Save as PDF writes its name into both fields, because Word both authored the document and wrote the PDF. Send the same document through Acrobat's plug-in instead and you get Created with: Acrobat PDFMaker 23 for Word, Produced by: Adobe PDF Library 23.3, because that route had two vehicles in it.

Why they sometimes disagree with each other

Here is the part that catches people out. Producer is rewritten; Creator is inherited.

Most programs that open a PDF and save it again stamp their own name into Producer, because they genuinely are now the thing that produced the file you are holding. They leave Creator alone, because they did not author anything. So a document that started in Word and was later shrunk with Ghostscript reads Created with: Microsoft Word, Produced by: GPL Ghostscript 10.02.1 — and it is telling you the truth about both moments in its life.

That is why Producer is the more revealing of the two. Creator is usually a fossil from the day the document was written. Producer is a note about the last program that touched it, which is very often not a program you chose deliberately or would think to mention.

Not every tool does this. Ours do not: the fields come back exactly as they went in unless you change them yourself. That is a deliberate choice, not an oversight — a tool that silently overwrites Producer is editing a provenance record.

What you can actually read off them

This is the useful bit, and the reason it is worth glancing at these fields on a file that is misbehaving. The Producer string frequently explains a symptom you are already chasing.

None of this is secret. It is the equivalent of a printer's mark. But it is specific, and specific things add up: a version number plus a creation date plus a department's peculiar toolchain is a reasonably narrow fingerprint of where a document was made.

Reading them on your own file

Any reader shows both under Document properties. If you would rather not open the file, our PDF inspector reads the properties in your browser without uploading anything — though be aware it prints Produced by and not Created with, along with the title, the author, the dates and whether there is a text layer. For both fields at once on the command line, pdfinfo file.pdf from poppler-utils prints the lot in about six lines and is the fastest way to check a folder full of them.

Clearing them

Almost always, leave them alone. They are not embarrassing, and a document with no Producer at all is slightly odd-looking in its own way. The cases where it is worth ten seconds are narrow: a tender or RFP response going to someone who also receives your competitors' files, a document leaving your organisation for the first time, or anything where your internal toolchain is not a thing you want itemised.

Our metadata editor has a box for each, so you can:

  1. Type a replacement into Created with and Produced by, leaving every other box empty. Empty means leave that field as it is, so correcting these two will not blank your title or author.
  2. Or tick "clear everything first", which throws away the entire information dictionary and then applies whatever you did type. Leave the boxes empty as well and the document says nothing about itself at all.
  3. Reopen the result and check the properties. If a value survived, the file carried a second copy of it — see below.

Do not put a false name in there

The boxes will accept anything. Resist it. A Producer string naming a program that never touched the file is a false statement about the document's provenance, sitting in the field investigators and opposing counsel check first — considerably worse to be caught at than whatever the true value said. An empty field reads as ordinary hygiene. A wrong one reads as an attempt.

It would not work anyway. Programs leave fingerprints in how they build a file — object ordering, compression choices, how they encode dates — that survive any amount of editing to the properties.

What clearing does not do

It removes a byline about your software. That is all it removes. The names in the text are still in the text, comments still carry their authors, embedded attachments still carry their own metadata, and photographs inside the document still carry whatever their camera wrote. If your reason for clearing these fields is that the document must not be traceable to you, that is a much bigger question and the answer is no.

When the old value will not go away

A PDF can describe itself twice: the information dictionary, and an XMP packet holding the same facts in a different notation, where Creator is xmp:CreatorTool and Producer is pdf:Producer. Readers disagree about which one wins. Edit only the dictionary and half your software shows the new value while the other half shows the old — the same mechanism that keeps a stale "Microsoft Word - Draft3" in the browser tab long after someone fixed the title. Our tool drops the XMP block whenever you change a field, and says so in the run notes.

On the command line, with one real trap

For a folder of files, or for the XMP as well as the dictionary, ExifTool is the right instrument:

exiftool -Creator= -Producer= -XMP:all= document.pdf

It does not delete anything. ExifTool writes PDFs as an incremental update: it appends the new, empty values to the end of the file and leaves the originals sitting in the bytes above them, fully recoverable by anyone who looks. This surprises people who thought they had cleaned a document. Follow it with a rewrite that keeps only what is reachable:

qpdf --linearize document.pdf clean.pdf

Now the old values are actually gone. qpdf is free, tiny and on every platform. Ghostscript will also rebuild the file, but it stamps its own name into Producer as it goes, so you end up having swapped one fingerprint for another.

One more field, on the outside

The file name is not metadata and no tool can strip it, but it travels with the document and it is read by everybody. Tender response - Acme - v4 FINAL (Dave's copy).pdf gives away more than any Producer string ever will. Rename PDF sets a sensible name and, if you let it, puts the same string inside as the document title so the two stop disagreeing. Note that renaming alone hands your bytes straight back untouched, but asking for the matching title means the file is written out again — so if you are doing both jobs, do the metadata one first.

Tools this post uses: