Remove PDF Metadata and Prove It Is Really Gone

When you remove PDF metadata, the awkward part is not the removing — it is believing the result. A cleaner says "done", the file downloads, and the author field is empty in the properties panel. Then somebody opens the same file in a different reader and your name is still there. This page is about the check that tells you which of those two things is true, and about a tool that now performs that check on its own output before it will hand you a file.

The PDF metadata remover reads both places a PDF hides its details, strips them, and then re-opens the produced bytes as a fresh document to prove what is left. Everything below was measured by driving that real page in Chrome on a real file — not by reading a specification.

Why "metadata-free" can still contain your name

A PDF keeps the same facts in two independent stores. The Info dictionary is a small dictionary referenced from the trailer: Title, Author, Subject, Keywords, Creator, Producer, CreationDate, ModDate. The XMP packet is a stream of XML hanging off the document catalog, carrying dc:creator, xmp:CreatorTool, timestamps and a document UUID. They are written independently, and they routinely disagree.

On the file I used, the Info dictionary was 283 bytes and the XMP packet was 931 bytes — three times the size, with a second copy of the author’s name inside it. pdfinfo reported both: Author: Priya Raman and Metadata Stream: yes. Empty the dictionary and the packet still answers the question. Empty the packet and every reader still shows /Author.

That is the whole reason a cleaner can be wrong without lying. It deleted something. It just did not delete everything.

What the page currently ranking actually tells you

Smallpdf’s guide, "How To Remove Metadata From PDF Files", is worth reading because it is honest about the failure. Its FAQ asks, verbatim: "Why does metadata still appear after I remove it?" and answers: "Some PDFs store metadata in different layers or embedded objects. Try saving the file as a new PDF ('Print to PDF') or using the Flatten PDF tool to remove all hidden layers." In other words, if the first attempt leaked, try a second method and hope.

The same page’s instructions are to "Drag and drop your PDF into the Compress PDF tool", then "Download your metadata-free file. Done." — a compression tool used as a metadata remover, with the result asserted rather than checked. Its pros-and-cons table concedes "Requires internet connection, so large files may take longer to upload", batch cleaning is gated behind "With a Smallpdf Pro account", and its "How to Check for Metadata in a PDF" section tells you to open Document Properties. That panel reads the Info dictionary. It cannot show you the XMP packet, so following it can produce exactly the false clean bill of health the FAQ is apologising for.

Those are specific weaknesses, and they are the opening: a tool that names both stores, and then proves the produced file, rather than asking the reader to take its word for it.

Measured: one real file, before and after

I uploaded a one-page, 1,961-byte PDF carrying eight Info fields and one XMP packet to the tool in Chrome. The row came back in 574 ms with 1,961 bytes → 604 bytes, 8 Info fields + 1 XMP packet removed, and a -69% badge. The download was quarterly report-clean.pdf, 604 bytes.

Then I checked the bytes on disk with tools that have nothing to do with the engine:

• grep -a "Priya Raman" output.pdf — 0 hits. The title, the string xpacket, the trailer /Info entry and the catalog /Metadata entry were all absent too.
• pdfinfo output.pdf — still Pages: 1, and no Author line at all.
• qpdf --check output.pdf — "No syntax or stream encoding errors found", with no warnings. Stripping metadata did not leave a damaged file.
• pdftotext output.pdf - — still printed META-MARKER. The page content, the text and the page count survived; only the descriptive data went.

The surprise was how much of the file was metadata: 1,357 of 1,961 bytes disappeared, 69% of a document whose visible page never changed. That is why "sometimes" in the answer to "does removing metadata reduce file size?" is too modest a word for a small document. On a 40-page scan it would be invisible; on a one-page letter it is most of the file.

The check that was added to the tool itself

A report that says "8 fields removed" is a claim about what the code did to the document it was holding in memory. It is not a claim about the bytes a recipient will open. pdf-lib serialises every object it has loaded, so an object merely unhooked from the catalog can still be written into the output. The difference is not theoretical: it is the difference between deleting a value and deleting the object that holds it.

So the tool now saves the PDF, then re-opens those saved bytes with a fresh parser and reads them as a stranger would. The report ends with a VERIFIED section: Re-opened the produced 604 bytes as a new document: 0 Info fields left, no XMP packet left. The row itself says verified clean. If the second read finds a leaked field or a surviving packet, the download is refused with a sentence naming what is left, and the original is unchanged — you do not get a file with a confident label on it.

Switch the "What to do" control to "Keep the title" and the same check runs under the new rule: the produced file still contains the title, and the report says 1 Info field left (Title, kept on request), no XMP packet left. I downloaded that variant too and checked it: title present, author absent, packet absent. A verification that cannot accommodate a deliberate exception would be a nuisance, not a proof.

How to check any cleaner’s output yourself

You do not have to trust this tool, or any other one. Three commands, in order, on the file that was actually downloaded:

1. Ask a second reader. pdfinfo file.pdf prints the Info-dictionary fields. pdfinfo -meta file.pdf prints the XMP packet. If either shows your name, the file is not clean — and note that a properties panel in a GUI reader shows only the first of those.
2. Look at the structure, not the summary. qpdf --qdf --object-streams=disable file.pdf out.qdf expands compressed object streams into readable objects, so a dictionary hiding inside one cannot escape a text search. Then grep -a -n "/Info\|/Metadata\|dc:creator" out.qdf.
3. Search the raw bytes. grep -a "Your Name" file.pdf and grep -a "xpacket" file.pdf. A name can sit in an orphaned object that no reader surfaces, and grep does not care whether it is reachable.

Do this on the produced file, not the original, and do it after the last save — saving a PDF in an editor can stamp a fresh Producer and ModDate back onto it. If you want the document to stay readable by older software, qpdf --check also tells you whether the cleaning damaged the structure.

The awkward files, and what happened to them

A clean happy path proves very little, so the same browser run fed the tool five difficult inputs:

• A UTF-16 XMP packet. Producers are allowed to write the packet as UTF-16 with a byte-order mark. Decoding it as UTF-8 turns the report into mojibake. The report showed the title correctly and contained no replacement characters.
• A PDF with no metadata. The row said nothing to remove and the report said the file carries no Info dictionary and no XMP packet. The bytes were handed back unchanged rather than rewritten for no reason.
• A PDF cut short at 92%. This is the interesting one. A truncated PDF can still be parsed by pdf-lib’s fallback scanner, which finds page objects but cannot attach the author to a trailer — so a cleaner can report "no metadata" for a file whose raw bytes still contain the name. The tool refuses instead, with "This PDF is incomplete — it stops before the end of the file, so its metadata cannot be read reliably." It never claims a truncated file is clean.
• A renamed text file. Refused as "That file is not a PDF" rather than failing silently.
• A password-protected PDF. Refused with a sentence explaining that its metadata cannot be read without the password. No blank screen, no partial output.

Why doing this locally matters here more than usual

A metadata remover is the one PDF tool where the file may be the reason you are cleaning it: a contract, a payslip, a medical letter, a draft with your name in the edit history. Smallpdf’s page says large files "may take longer to upload" — uploaded to somebody else’s server, where the very thing you wanted gone now exists on a disk you do not control. Adobe’s guide reminds you that once metadata is deleted it cannot be undone, which is good advice about saving, not about where the file travels first.

This tool reads and rewrites the file in the browser tab. Nothing is uploaded, so there is no queue, no per-file limit, and no copy of the document to delete afterwards. Once the page has loaded you can disconnect and it still works.

The short version

A PDF stores your details twice — in the Info dictionary and in an XMP packet — and clearing one leaves the other. Whatever cleaner you use, verify the produced bytes with a second reader, an expanded structure and a raw text search. If the cleaner re-opens its own output and refuses to download a file that failed the check, so much the better: that is the difference between a claim and a proof.

If you have a file ready, open the PDF metadata remover and read the VERIFIED section at the end of the report. Use "Report only" first if you just want to see what the file is carrying before changing anything.