Edit PDF metadata

Six fields are editable: Title, Author, Subject, Keywords, Producer and Creator. They live in the PDF's Info dictionary, and every desktop reader surfaces them somewhere — Acrobat under File, Properties, Description; macOS Preview under Tools, Show Inspector; Windows Explorer in the Details tab of a file's properties. Title has the widest reach: many viewers show it in the window or tab bar instead of the file name, cloud previews use it as a heading, and search engines will use it when a PDF is indexed on a public site. Producer and Creator are the software fingerprints — Creator names the program that authored the original, Producer the one that wrote out the PDF.

Clearing a field writes an empty string in its place, and the download is a complete rewrite rather than an appended revision, so the old Info value is not carried along inside it. That distinction matters: PDFs can be saved incrementally, tacking changes onto the end while the previous version survives further up the file, and a document edited that way can still be mined for its earlier values. This tool does not save incrementally. What it cannot promise is that the same string appears nowhere else in the document — inside an XMP packet, an annotation's author entry or the visible page text — which is the subject of the next answer.

Edit PDF metadata touches the Info dictionary and nothing else, so several other carriers of identifying data survive untouched. XMP metadata, a separate XML packet many producers embed alongside the Info dictionary, is left exactly as it was, which is why an XMP-aware reader may still display an old author name. Annotation and comment author names, embedded file attachments, EXIF data inside embedded photographs, form field values and the visible text of the pages themselves are all outside this tool's scope. The document's File ID is regenerated on save, but other producer fingerprints inside object streams are not touched. Where hidden data genuinely matters, use Redact PDF in Wipe mode, which rebuilds the file and leaves those structures behind on purpose.

The creation and modification dates are deliberately preserved rather than exposed, so the tool does not turn into a convenient way to backdate a document. The PDF is loaded with pdf-lib's automatic metadata updating switched off, which stops the library stamping its own producer string and a fresh modification date over the originals simply because the file was opened — that would have made the mutated values appear as the before side of the diff and then be written straight back out. The result is that the dates you had going in are the dates you have coming out. To see what a file currently records, dates included, open it in PDF info viewer.

Encryption is the usual reason a PDF will not load in Edit PDF metadata. The tool has to parse and rewrite the document, and it will not do that through a security handler, so a password-protected file simply reports that it could not be read. Unlock it with Remove PDF password first, edit the fields, and re-protect it with Add password to PDF afterwards if you still want it encrypted — the encryption step has to come last, since rewriting metadata requires an unencrypted file. The other cause is genuine damage: a truncated download, or a file that is not really a PDF despite its extension, fails the same way, and there is no reliable browser-only repair for that. In both cases the tool says the file could not be read rather than writing out a document it never parsed properly.

The component reads and rewrites the six fields with pdf-lib in the browser and does not post the selected document or edited values to a processing service. The saved copy has a -metadata suffix and no PDFChamp page stamp. This tool only covers the Info dictionary; check the privacy policy separately for site-level analytics and remember that XMP, annotations and embedded-image metadata are outside its scope.