File & PDF Tools

Edit PDF Metadata

Inspect and edit PDF title, author, subject, and keywords.

Edit PDF metadata
Inspect and update title, author, subject, and keywords.
Local browser processing

Edit PDF Metadata

Inspect and update title, author, subject, keywords, creator, and producer fields in the document information dictionary.

Boundaries

  • Separate keywords with commas
  • The modification date is updated on save
  • This does not remove page content, attachments, or all hidden data

Reads and rewrites the six entries of a PDF document information dictionary — Title, Author, Subject, Keywords, Creator and Producer — inside the browser, then saves a new file. Suits publishing preparation: removing a real name from Author, an internal toolchain name from Producer, or filling in a title that readers show in their window bar.

The info dictionary and the XMP packet beside it

Each field maps to one key in the trailer information dictionary: Title, Author, Subject, Keywords, Creator, Producer — the entries defined in PDF 32000-1 section 14.3.3. Modern producers usually attach a second, independent copy of the same facts as an XMP packet, referenced from the catalog /Metadata stream. This editor rewrites the dictionary only, and the XMP packet is carried through byte for byte. Acrobat and several other viewers give XMP precedence when both copies exist, so a saved file can keep showing the old title under Document Properties while the dictionary already holds the new one. Bringing both copies in line is a re-export job, not a dictionary edit.

Why saved values become UTF-16BE hex

The library writes every entry through PDFHexString.fromText: the byte order mark FE FF, then two bytes per character. A twelve-character title such as pdf metadata therefore occupies 26 bytes and appears as the run FEFF0070006400660020006D0065007400610064006100740061 — twice the ASCII size and unreadable in a text dump, but this is what keeps a Chinese title intact for viewers that would otherwise decode the string as PDFDocEncoding. Clearing an input does not delete its key: an empty value is stored as the bare FEFF mark, so Document Properties still lists Title, with zero characters. Keywords follow the same path, except the list is joined with single spaces before storage.

Dates, Producer, and why the output is not a minimal patch

The document is parsed with updateMetadata disabled. That option defaults to on, and its default action rewrites /Producer with the pdf-lib name and stamps a fresh /ModDate the instant a file is opened, erasing the provenance you came to inspect; switching it off keeps Producer exactly as the file declared it until you type a replacement. Saving sets /ModDate to the current UTC time in the D:YYYYMMDDHHmmssZ form of section 7.9.4 — second precision, no offset — while /CreationDate is never touched. Output is written with object streams, so the file is repacked rather than patched: existing digital signatures stop verifying, and encrypted files are refused before any edit.

Worked example

Saving a Chinese title with two keywords

Input 
Title: 季度报告
Keywords: pdf, 归档
Output 
/Title = FEFF5B635EA662A5544A
/Keywords = FEFF00700064006600205F526863

Four CJK characters at two bytes each, behind the FEFF mark, give 10 bytes printed as 20 hex digits. The comma never reaches the file: the form splits on commas, then the library joins the pieces with a single space, so what is stored is pdf 归档, and reopening the file yields one space-separated keyword string.

Limits and pitfalls

  • One file per run, 100 MB maximum; parsing happens in the page, so a file near that ceiling also keeps its bytes and parsed objects in tab memory until you reload.
  • The comma is a form convention, not a PDF one: /Keywords is a single space-joined text string, so a list typed as pdf, 归档 is stored as pdf 归档, and a viewer that splits on commas shows one run-on term.
  • Clearing an input keeps the dictionary key with an empty value, so an inspector still lists Title with zero characters instead of the entry disappearing.
  • Only the information dictionary changes; XMP, attachments, annotations, bookmarks and page content are copied through, and any existing digital signature fails verification because the file bytes changed.
  • Password-protected or encrypted PDFs are rejected before editing — decryption has to happen first, since the tool cannot parse a document it cannot read.

Related tools

  • Flatten PDF Forms — Bake PDF form fields into page content to prevent further editing.
  • Merge PDFs — Reorder and combine multiple PDF files into one document.
  • Extract PDF Text — Extract an embedded PDF text layer and export it as TXT.

When it goes wrong

Any PDF that already carries keywords vanishes the moment I drop it, leaving only "document.getKeywords(...).join is not a function".

CauseThe prefill line passes document.getKeywords() ?? [] straight into .join, but pdf-lib 1.17.1 returns the decoded /Keywords text as one string, not an array. The empty-array fallback only covers files with no /Keywords key, so the crash waits for exactly the files whose keywords you came to edit. It is thrown inside the loader, which empties the file list and prints the raw message, since no friendly-text entry matches it.

FixStrip the key once, then reopen the file here: load it with updateMetadata: false, run doc.getInfoDict().delete(PDFName.of('Keywords')), save. The Keywords box now prefills empty, and your next save writes a fresh /Keywords entry from whatever you type.

I saved a new title, but the reader window still reads report-final-v3.pdf.

CausesetTitle is called without options, so only /Title in the information dictionary changes. Acrobat substitutes /Title for the file name in its title bar only when the catalog carries viewer preferences with /DisplayDocTitle true, and pdf-lib sets that flag solely through its showInWindowTitleBar option, which this tool never passes. Document Properties shows the new title; the window chrome keeps the name.

FixRename the download if the window title is what matters — it arrives as name-metadata.pdf. A real /DisplayDocTitle needs setTitle(title, { showInWindowTitleBar: true }) run over the saved file in a script; no box in the form can add it.

I typed two keywords with a Chinese comma and the properties panel shows one long term instead of two.

CauseThe split is a literal keywords.split(','), so only U+002C separates. A full-width comma U+FF0C is an ordinary character, which leaves "pdf，归档" as a single token after the trim and empty-filter steps; the library then joins that one-element array with a space and hex-encodes it.

FixRetype with half-width commas and save again. Semicolons, ideographic spaces and line breaks fail the same way, so split on the ASCII comma only.

I only changed the title, yet the saved file now lists Author, Subject and Keywords with nothing in them.

CauseAll six setters run on every save whether or not the box is filled, and each writes PDFHexString.fromText(value). An empty string becomes the bare two-byte BOM, <FEFF>: a key that exists and decodes to zero characters. A dictionary that had no /Author at all therefore gains one.

FixFill Author, Subject and Keywords in the same pass if the file is going out — all six boxes are prefilled from the document, so untouched non-empty fields round-trip unchanged. To have the keys disappear, delete them afterwards with delete(PDFName.of('Author')); writing an empty value never removes a key.

One concrete scenario

A 32-page audit report going out with a corrected byline

A 32-page audit report is leaving for a client with Author still reading 张伟 (Finance-IT). Those 15 characters cost 2 bytes each behind the FEFF mark — 32 bytes, printed as 64 hex digits; the replacement Finance-IT costs 22 bytes, or 44 digits, so that single entry shrinks by ten bytes. Nobody will notice that beside 32 pages, which means there is nothing to optimise in these six boxes and everything to get right in the order of operations. Every save runs setModificationDate(new Date()) and stamps /ModDate with the UTC second it happened, so three partial passes bury the original timestamp under three later ones. Fill all six fields, save once, verify in Document Properties, then rename the downloaded name-metadata.pdf.

Frequently Asked Questions

What lives in PDF metadata? What can it leak?
Title, author, subject, keywords, creator software, and timestamps. Leak points: a real name in Author, internal system names in Producer, the document’s timeline. Clean it before publishing — same tier as stripping photo EXIF.
Can editing metadata prove authenticity?
No — metadata is freely editable and is not evidence; legal forensics rely on digital signatures and trusted timestamps. And conversely, metadata is publishing hygiene, not a privacy shield.
Why is there still info in file properties after cleaning?
Metadata lives in more than the info dictionary: an XMP stream is a second set (this tool handles both), and documents may also carry attachments, hidden layers, and annotations. The tool states its scope; deep cleaning means re-export or specialized tools.

Content reviewed: