← All posts

Why does my old PDF title still show up after I changed it?

You opened the document properties, typed the title you wanted, saved, and closed it. Then you reopened the file and the browser tab still says the old thing. Or your colleague's copy says the old thing. Or Explorer's details pane says it, cheerfully, in the same folder where you have just fixed it twice.

So you did it again in a different tool, and now you are not sure whether the change is failing to save or failing to show.

It is almost always the second. A PDF can carry its title in more than one place, readers disagree about which place wins, and the software around the file keeps its own copy of what it saw last week. Three different problems, three different fixes, and about five minutes to tell them apart.

Why a PDF can disagree with itself about its own title

There are two places a title can live inside the file.

The document information dictionary. The old one, and the simple one: a small object near the end of the file with /Title, /Author, /Subject, /Keywords, /Creator and /Producer in it. This is what most tools mean when they say "metadata", and it is the copy nearly every editor writes.

The XMP packet. A block of XML, embedded in the document catalogue, holding the same information again in a different vocabulary — the title is dc:title there. Adobe's tools have written it for twenty years, and any file that went through InDesign, Acrobat or a publishing pipeline almost certainly has one.

Nothing keeps those two in step. The specification does not say which one a reader must believe, so readers pick. Firefox's built-in viewer, which is pdf.js, looks at dc:title first and only falls back to the information dictionary if there is nothing usable there. Plenty of other software does the opposite. Windows Explorer, Spotlight, a document management system and Google's crawler each have their own opinion.

Now put a tool in the middle that writes only one of them. pdftk in.pdf update_info info.txt is the classic: it updates the information dictionary and does not touch the XMP at all. So does a fair amount of library code written by somebody who read half the spec. Afterwards the file honestly contains both your new title and the old one, and which you see depends entirely on what opens it. That is why it looks like the change did not save. It saved. It just did not save everywhere.

The same split explains the other metadata question people arrive with — a file that insists on calling itself Microsoft Word - Draft3 long after the text has been rewritten, and the creator and producer fields that quietly name the software your organisation runs.

Work out which copy you are looking at

Two minutes, before you edit anything else.

  1. Check you are opening the file you think you are. A browser that downloads report.pdf twice gives you report (1).pdf, and half of these reports are somebody editing one and opening the other. Sort the folder by date modified.
  2. Read the information dictionary. Our PDF inspector prints the title, author, producer and dates straight out of that dictionary, in your browser, without uploading the file anywhere. Be clear about what it is telling you: it reads the dictionary, not the XMP packet.
  3. Compare. If the inspector shows your new title and a reader shows the old one, there is a stale XMP packet in the file, or a cache outside it. If the inspector shows the old title too, the edit genuinely did not stick and you should do it again somewhere that works.
  4. Open the same file in Firefox as a second opinion. Because pdf.js prefers dc:title, a disagreement between Firefox's tab and Chrome's is close to a positive identification of a contradictory XMP packet.

Setting both copies at once

Our Edit PDF metadata writes the information dictionary and then removes any XMP packet it finds, so the file is left with exactly one answer instead of two. The run notes say when it happened: "The file's XMP block held a second copy of these fields and was removed." If you see that line, you have just found your problem.

Fill in only the fields that should change — an empty box means leave that field alone, so correcting a title does not blank the author. If the point is to strip the document rather than correct it, tick clear everything first, which also wipes the created and modified dates. There is no box for setting a date to a value of your choosing, deliberately.

When nothing in the file is wrong and the cache is

If the inspector and every reader agree on the new title but something else still shows the old one, the file is fine and you are looking at a copy of last week's answer.

None of these are PDF problems. All four get diagnosed as one.

When Acrobat shows the file name whatever you do

Different symptom, same frustration, and worth knowing because no amount of retyping fixes it.

The catalogue can carry a viewer preference called DisplayDocTitle. When it is absent or false — which is the default — Acrobat and Reader put the file name in the window title, ignoring the title you set. When it is true, they show the title. So a file can have a perfectly correct title and still display invoice_final_v3.pdf forever.

This also matters beyond tidiness: PDF/UA and the accessibility checkers built on it treat a missing DisplayDocTitle as a failure, because a screen reader announces the document title when the file opens.

Neither Edit PDF metadata nor Rename PDF sets that flag. In Acrobat it is File, Properties, Initial View, Window Options, Show: Document Title. Free, from a terminal, pikepdf does it in one line:

python3 -c "import pikepdf; p=pikepdf.open('in.pdf'); p.Root.ViewerPreferences=pikepdf.Dictionary(DisplayDocTitle=True); p.save('out.pdf')"

That replaces any other viewer preferences the file had, which for most documents is nothing.

When the old title is printed on the page

Worth ruling out early, because it is invisible to every metadata tool. If the stale title is the one in large type on the cover, that is page content and no properties dialogue on earth will change it. Editing the page itself is the job — see why that beats a round trip through Word.

The trap in between is a cover page built as a form field. It reads as ordinary text, it is not: it is a field holding a value from whatever the template last put in it, and some readers will happily display a value that is not written into the file at all. Retype the field, then use Flatten PDF to press it into the page so it stops being a field and starts being text. Keep the original, because there is no unflatten.

The command line, when you want to see both copies at once

The fastest honest look at this file is ExifTool, which is free and reads both copies separately:

exiftool -a -G1 -Title yourfile.pdf

[PDF] Title is the information dictionary and [XMP-dc] Title is the packet. If they differ, you have your diagnosis in one line. To set both:

exiftool -Title="Annual Review 2025" -XMP-dc:Title="Annual Review 2025" yourfile.pdf

One thing to know about that, because it surprises people: ExifTool edits a PDF by appending an incremental update rather than rewriting it. The new values win, but the old bytes are still in the file, recoverable with exiftool -restore_original and visible to anything that scans raw bytes. Follow it with qpdf --linearize in.pdf out.pdf to rewrite the document and leave the old revision behind. If you would rather do that in the browser, Repair PDF rebuilds the file page by page and has the same effect.

If it is the file name that is stuck, not the title

They are different things and they get confused constantly. The file name belongs to your disk. The title belongs to the document and travels with it, which is why a file called contract.pdf can introduce itself as something else entirely everywhere it goes. Rename PDF sets both in one pass — it gives the file the name you type and, unless you turn the option off, uses the same string as the document title, dropping any conflicting XMP packet on the way. Turn the option off when the document has a proper title of its own worth keeping.

If you only change the name, the bytes you uploaded are handed straight back untouched, which is the one case here where a digital signature survives.

Tools this post uses: