How to Edit PDF Metadata (the Info Dict, the XMP Packet, and the Field That Shows in Search)

That "Microsoft Word - report.docx" title in search results is metadata

You uploaded a PDF two months ago. Google indexed it. The search result reads "Microsoft Word - Quarterly Report.docx — yourdomain.com" — because the PDF's Title is whatever Word set at Save, and a PDF's Title is what Google tends to use for the heading of an indexed PDF. It's also the browser tab. A bad title costs clicks, and the fix is thirty seconds of metadata editing — if you edit the right block, and the editor doesn't quietly undo you.

The PDF Metadata Editor opens a PDF in your browser (pdf-lib, nothing uploaded), shows the six fields plus the dates, and writes your edits back. The simple part — typing a better title — works. The interesting part is the four ways this tool can defeat you without telling you, and the one place it doesn't edit at all.

The six fields, and the one that actually shows up in search

Field	What it's for	Who sees it
Title	The document's name	Browser tab, Google's search-result heading, "Document Properties"
Author	Who wrote it	Document Properties, some DAM systems
Subject	A one-line description	Document Properties; ignored by Google
Keywords	Index terms	Older cataloguing software; ignored by Google
Creator	The app that made the PDF	Document Properties
Producer	The library that output the PDF	Document Properties

The Title is the one that matters — Google leans on it for the result heading of an indexed PDF, browsers put it in the tab, readers see it in Properties. If it says "Untitled" or repeats the filename, that's what the world sees. Author and Subject are nice-to-have. Keywords are nearly dead — Google has ignored the keywords meta signal for over a decade, and PDF keyword fields are no different; fill them if your DAM needs them, don't expect traffic.

Two metadata blocks. The tool only sees one.

A PDF carries metadata in two separate places:

• The Info dictionary — the old, plain-text block of /Title, /Author, /Subject and the rest, in PDFs since the 90s.
• The XMP packet — an XML block (Adobe's standard) embedded in the file. Word, InDesign, Acrobat, and most modern tools write XMP, and many readers prefer it because it's structured.

pdf-lib — the engine behind this tool — has an API for the Info dictionary and no API for XMP at all. It can't read XMP, can't write it, can't update it. So the tool edits the Info dict and leaves the XMP packet alone. If your PDF came from Word, it has XMP, and a reader that checks XMP first shows the old values, not your edits. The two blocks quietly disagree. For a quick title fix on a PDF you generated yourself (no XMP, or you don't care about XMP), that's fine. For a PDF from a design tool where XMP is the source of truth, you need an editor that syncs both.

The four ways this tool quietly defeats you

All four verified by round-tripping a file through the tool.

1. The Producer field is overwritten on every save. Type anything into Producer — "Acrobat Distiller 23.0" — and save. Reload: the producer reads pdf-lib (https://github.com/Hopding/pdf-lib). pdf-lib stamps its own Producer into the output regardless of what you entered; the original is gone. Creator, in contrast, survives — pdf-lib leaves it alone. So you can edit Creator; editing Producer is pointless, because save() overwrites it.

2. Keywords don't split on commas. The placeholder says keyword1, keyword2, keyword3. The code does setKeywords([metadata.keywords]) — one array element, the entire string. Type "budget, forecast, q3" and you get one keyword, literally budget, forecast, q3, commas and all, not three. The input is a single string field with no splitter; you can't get three through this tool.

3. Empty fields aren't saved. Every setter is guarded with if (metadata.title) — clear the Author field and the empty string is falsy, the setter never runs, the original author stays. You can change a value; you can't delete one. (pdf-lib itself can clear a field — pass an empty string — but this guard skips it.) To strip metadata you need a different tool.

4. The modification date snaps to now if you clear it. The Modification Date loads pre-filled with the file's existing date, so leaving it alone preserves it. Clear the field and the guard skips — pdf-lib stamps the modification date to now on save. You can't remove the date; you can only set it to now. The Creation Date, sensibly, is read-only.

Summary

• The Title is the field that matters — what Google leans on for the search-result heading and what the browser tab shows. Fix it in the PDF Metadata Editor in seconds.
• PDF metadata lives in two blocks: the Info dictionary (old, plain text) and XMP (XML, modern). pdf-lib has no XMP API, so this tool edits the Info dict only — a PDF with XMP keeps the old values in the block the tool can't see.
• Four quiet traps: Producer is overwritten to "pdf-lib…" on save (Creator survives), keywords don't split on commas (one string, not a list), empty fields are skipped (you can't delete a value), and clearing the modification date sets it to now.
• For removing metadata or keeping XMP in sync, use exiftool or qpdf. For the rest of the PDF workflow: merge, split, or password-protect a file.