PDF Metadata Removal: "Fully Erased" vs. "Emptied" Aren't the Same
Reading the phrase "metadata removed" makes it easy to assume the information vanishes from the file entirely. But look at how a PDF is actually structured internally, and how the libraries that manipulate it behave, and "removed" turns out to mean something different depending on the field. For some fields the value simply becomes an empty string while the field itself stays in the file; for others the key itself disappears from the file's structure. Based on the actual code behind the PDF metadata remover, here's why that asymmetry exists and why it matters in practice.
1. Where PDF metadata is stored
A PDF document's information lives in a key-value dictionary in the file structure called the "Info Dictionary." It holds 8 standard fields: Title, Author, Subject, Keywords, Creator (the authoring application), Producer (the PDF generator), CreationDate, and ModDate. This is the same dictionary any PDF viewer exposes through a "Document Properties" menu, and it's also the dictionary you manipulate directly when working with a PDF in the browser using a library like pdf-lib.
2. Why "deleting" behaves differently field by field
For six fields — Title, Author, Subject, Keywords, Creator, and Producer — pdf-lib only provides "setter" functions like setTitle() and setAuthor(). These functions are designed to write a new value, so a "delete" request actually gets handled as "rewrite it as an empty string." The two date fields, CreationDate and ModDate, don't have dedicated setters at all — instead, you can delete the key directly from the Info Dictionary itself using getInfoDict().delete(). In other words, the shape of the API the library exposes is different for each field, so pressing a single "remove" button actually triggers two different operations under the hood.
doc.setTitle('') · doc.setAuthor('') · doc.setSubject('') · doc.setKeywords(['']) · doc.setCreator('') · doc.setProducer('') — 6 fields get overwritten with an empty value. infoDict.delete(PDFName.of('CreationDate')) · infoDict.delete(PDFName.of('ModDate')) — 2 fields get their key deleted entirely.
3. What's actually left in the resulting file
Check the boxes, run the removal, and open the resulting PDF in a different viewer: fields like title and author may show up as "empty string" rather than "no value." Some PDF viewers and file-property inspection tools distinguish between the two, so a user expecting the field to be completely gone may instead find it recognized as still existing, just blank. The creation and modification dates, on the other hand, end up with the field genuinely absent — meaning the same tool, the same button, can produce different inspection results depending on which field you're checking.
| Field | How it's processed | State in the resulting file |
|---|---|---|
| Title / Author / Subject / Keywords / Creator / Producer (6 fields) | Overwritten with an empty string | Key exists, value is blank |
| CreationDate / ModDate (2 fields) | Key deleted from the Info Dictionary | Key doesn't exist at all |
4. Why this difference matters in practice
The point of clearing metadata before distributing a company document externally is usually to hide "which computer, which program, and when" produced the file. Whether a value is an empty string or the key is simply gone, the result looks the same to a human opening the "Document Properties" window — either way, the information isn't exposed. But if a file is inspected programmatically — say, by an automated script that only checks whether a specific key exists — "the key exists but is empty" and "the key doesn't exist" can be detected differently. If you're working under strict verification requirements, it's worth knowing about this asymmetry.
5. How to verify the result afterward
Regardless of which method cleared a field, the most reliable way to confirm it worked as intended is to re-upload the resulting PDF to the same tool and check the "current metadata" table. This tool only enables the checkbox for fields that have a value, so if all 8 fields come back empty or unlisted on re-upload, the removal worked correctly. To cross-check other structural details of the PDF file itself, you can also use a PDF metadata viewer or a PDF size analyzer.
Frequently Asked Questions
Q. Does "overwrite with an empty string" vs. "delete the key" make any difference to the resulting file size?
The difference is negligible. Both methods replace the original value with something far shorter, so file size actually goes down slightly either way. There's no size difference you'd notice with the naked eye between the two approaches.
Q. Why not just delete all 8 fields' keys instead of mixing methods?
Because the pdf-lib library only provides setter functions for the 6 fields like Title and Author — it doesn't expose a function to delete those keys directly. It would be possible by manipulating the Info Dictionary at a low level, but this tool sticks to the library's standard API as provided.
Q. Does this also remove XMP metadata?
This tool only handles the Info Dictionary. PDFs can separately carry XML-based metadata called XMP (Extensible Metadata Platform), and clearing the Info Dictionary doesn't touch that — the same information may still be sitting in the XMP stream. If you're worried sensitive information might also be in XMP, you'll need to check separately with another file-properties tool.
Q. What happens to fields I don't check?
They stay exactly as they were. The save logic rewrites unchecked fields with their original value, so anything you didn't select is unchanged before and after removal.