PDF Metadata Editor

1. 1

   Open your PDF

   Drop a PDF onto the page or browse for one. It is read on your device and never uploaded.

2. 2

   Read what it says now

   The table fills with the document's current title, author, subject, keywords, creator, producer and both dates.

3. 3

   Change only what you want

   Type into a field to change it, or clear it to remove it. Fields you do not touch are left exactly as they are.

4. 4

   Apply and check

   Press Apply. The tool re-reads the saved file and shows you, field by field, what it now contains.

5. 5

   Download

   Save the edited PDF, or collect a whole batch as one ZIP.

Metadata is what a document says about itself before anyone opens it. It is the line a reader shows in its window title, the text a desktop search matches, the author a document management system files the record under, and the fields a court's e-filing portal or a client's ingest pipeline validates on receipt. When it is wrong — and it is usually wrong, because it was inherited from a template, a scanner or whichever program happened to export the file — the document is harder to find, harder to trust and occasionally rejected outright.

What accurate properties actually buy you

• Findability: desktop search, SharePoint, Google Drive and every document management system index the title and keywords long before they index page text, and a scanned document has no page text to index at all.
• A title that is not a filename: readers show the Title property in the window and the tab, so a document exported as "Document1" announces itself that way on a shared screen no matter what the file is called.
• Privacy before sharing: author, creator and producer routinely carry a real person's name, an internal machine name or the exact version of the software that made the file. All three go out with the document unless somebody removes them.
• Consistency across a set: a folder of exports where the subject field means the same thing in every file is a folder you can filter; one where it means whatever each author felt like is not.
• Compliance and conformance: PDF/A requires the document properties and the XMP packet to agree, and archives, regulators and publishers check it.

This is the single most important thing to understand about editing a PDF's properties, and it is where almost every free editor quietly gets it wrong. A PDF stores the same facts in two independent structures, and nothing in the format forces them to agree.

Document properties and XMP, side by side

• The document information dictionary: the original mechanism, present since PDF 1.0. A short list of key and value pairs — Title, Author, Subject, Keywords, Creator, Producer, CreationDate, ModDate — attached to the file's trailer. Simple, small, and what most libraries read and write.
• The XMP packet: an XML document embedded in the file, using Adobe's Extensible Metadata Platform. It carries the same eight fields under standard vocabularies (Dublin Core for title, creator and description; the PDF and XMP namespaces for keywords, producer and dates) and can carry far more besides — edit history, rights statements, conformance claims, whole custom schemas from an asset manager.
• Who reads which: Acrobat, most indexing systems and most digital asset managers prefer XMP when it is present. Many programming libraries only ever look at the dictionary. Neither is wrong; they are reading different parts of the same file.
• How they drift apart: one program updates the dictionary, another updates the packet, and after two or three hops the file is telling two different stories. Nothing warns anybody, because nothing is invalid.

This editor reads both the moment you open a document. If they disagree it says so, field by field, showing you what each one claims. When you apply your changes it writes both from the same values and then re-reads the file to confirm they now match — and if they somehow do not, the save fails rather than handing you a document that contradicts itself.

The eight standard properties are not interchangeable, and using them as intended is most of what makes a document findable later.

The eight standard properties

• Title: the document's real name, as a person would say it. Not the filename. This is what a reader displays in its window and what search results show.
• Author: the person or team responsible for the content. Separate multiple names with commas; they are written as an ordered list in the XMP packet.
• Subject: a one-line description of what the document is about. Treated as a description in XMP, which is why it can be longer than a title without looking wrong anywhere.
• Keywords: comma-separated terms for retrieval. A handful of terms somebody would actually type beats thirty that nobody would.
• Creator: the program the content was authored in — Word, InDesign, LaTeX. Often the most identifying field in the whole file.
• Producer: the program that wrote the PDF itself, which is usually a converter or a print driver and usually names its exact version.
• Created and Modified: timestamps, with a time zone offset. Both are shown here in your own local time and written back with the offset the document already used, so editing a wall-clock time does not silently move a document from Berlin to UTC.
• Custom properties: any additional key and value you want — matter number, client code, retention class, cost centre. They live alongside the standard eight and are mirrored into the XMP packet under a custom namespace.

Stripping properties is a different job from editing them, and it is the one people most often do badly. Setting a field to an empty string is not removal: the entry is still there, still says the document has an author, and still shows as a blank line in a reader. Removing the entry is what makes it absent.

What Clear all actually does

• Removes all eight standard entries from the document properties, rather than blanking them.
• Removes every custom property.
• Deletes the XMP packet outright, so no copy of the old values survives in the XML.
• Overwrites the superseded entries in place before appending the new state, so the removed text is not left sitting earlier in the file where a text search would find it.
• Adds no producer string, no toolkit name and no new timestamp of its own on the way out.
• Re-reads the finished file and fails the save if any field, in either location, still holds a value.

Two things it deliberately does not do. It does not touch anything drawn on a page — a name in a letterhead, a signature block, a comment or an annotation is page content, not metadata, and removing it is a different tool's job. And it does not claim to defeat forensic recovery of a file you have already shared: it can only change the copy you download from here. If you need only some of the identifying fields gone, Anonymise clears author, creator, producer and any custom properties while leaving the title, the subject and the keywords in place, which is usually what "ready to send outside" actually means.

The whole thing runs on your device. Nothing is uploaded, there is no queue on a server, and there is no file to be deleted afterwards because there was never a copy anywhere else. What is unusual is how little of your document it touches.

What happens when you press Apply

• Read the tail, not the file: a PDF's cross-reference table sits at the end and points at everything else, so finding the properties takes four object reads rather than a full parse. This is why opening a 500-page scan is as quick as opening a one-page invoice.
• Change only the entries you edited: the bytes of every property you did not touch are copied across verbatim, not re-serialised. A value stays in exactly the character encoding it arrived in.
• Overwrite the old entries, then append the new ones: the superseded properties are blanked where they sit, and the new state is appended. The rest of the document — every page, every font, every image — is untouched, byte for byte.
• Fall back completely, never partially: a few documents pack their properties inside a compressed object stream, where the old bytes cannot be overwritten in place. Those are rebuilt in full instead, which is slower and produces the same result.
• Verify before you see it: the finished bytes are read back and checked — every field you changed holds what you asked for, every field you did not is unchanged, and the two storage locations agree. A failure stops the save instead of reaching your download.

Reads and rewrites only the few hundred bytes that hold a document's properties, so a 100 MB file costs the same as a 100 KB one.

A metadata policy that fits on an index card is one people follow. These are the rules worth the effort, drawn from the way legal, finance and agency teams actually use these fields.

Quality and compliance tips

• Make the title match the heading on page one. If a person reading the document would not recognise the title, it is the wrong title.
• Prefer a handful of keywords somebody would genuinely type over an exhaustive list nobody would.
• Check creator and producer before anything leaves the building. They are the fields most likely to name a person, a machine or an unlicensed piece of software.
• Keep subject values inside whatever taxonomy your team already uses, so the field can be filtered rather than merely read.
• Keep the original when you are editing a document that is under a retention or evidentiary obligation. Editing metadata changes the file's bytes, and the copy you started from may be the record.
• Set the dates deliberately rather than leaving whatever the exporting program stamped. A creation date of "whenever the print driver ran" is worse than no date.

Common use cases

• Legal: normalise properties across a production set before filing or exchange, and remove the author and producer fields that would otherwise identify the drafting machine.
• Finance and operations: give a folder of exported invoices or statements a consistent subject and keyword scheme so the archive is searchable years later.
• Agencies and studios: strip the tool-specific producer string and the internal author name before a client handoff, while keeping the title and description that make the file useful.
• Publishing and archives: bring the document properties and the XMP packet into agreement, which is a hard requirement of PDF/A and a common cause of failed conformance checks.
• Research and libraries: correct the title and author on scanned material so a repository indexes it under something other than the scanner's default.

A few figures that explain why this tool is built the way it is.

Measured on this tool

• 8 standard fields, 2 storage locations: sixteen places a value can live, and no rule in the format that they agree.
• About 250 bytes appended for a typical edit: the rest of the file is copied through unchanged, whatever its size.
• Independent of page count: a 500-page document and a one-page document take the same work, because neither has its pages read.
• Up to 50 documents in one batch with Pro: one set of values, applied across all of them, with every untouched field left alone in every file.
• 3 independent readers agree: every result this tool produces is checked against two other PDF implementations before it ships.

• Compress PDF
• Add PDF page numbers
• Merge PDF files
• Rotate PDF pages
• Add a PDF watermark
• Fill a PDF form