2026-08-18

Clearing your manuscript's hidden metadata before a double-blind peer review submission

Submitting to a double-blind venue comes with a familiar checklist: strip your name and affiliation from the title page, rewrite "as we showed previously" into something that doesn't out you as the author, move acknowledgments into a separate cover letter. What gets missed more often is a step Nature spells out plainly in its own author checklist for double-blind submissions: "Ensure there is no author information in the metadata of any of the submitted files. This information is usually added automatically from the identity information on your computer." A manuscript is a file with its own hidden fields, entirely separate from the text a reviewer reads on the page — and anonymizing the visible page doesn't touch them.

What the checklist is actually pointing you toward

Nature's checklist doesn't just say metadata exists; it says where to look: "In many commonly used programmes, such as Word, author information is displayed (and can be edited) in the 'File' tab under 'properties'." That's the same dialog the resume-writing world calls the Properties box — under the hood, for a .docx, it's docProps/core.xml (author name, last-modified-by), docProps/app.xml (Company, Manager, often auto-filled from whatever organization is registered to the Office install that created the file), and docProps/custom.xml (any free-form custom properties a template or reference manager added). A PDF version carries the same kind of information in a different shape: an Info dictionary with Title, Author, Subject, Keywords, Creator, Producer, and two timestamps, plus, separately, an XMP metadata stream that can duplicate or extend the same fields. None of it is visible on the page. All of it travels with the file to every reviewer who opens it.

How often this actually happens

This isn't a hypothetical. A 2021 study, "Exploitation and Sanitization of Hidden Data in PDF Files" by Supriya Adhatarao and Cédric Lauradoux, pulled 39,664 real-world PDF files published by 75 security agencies across 47 countries and checked what their own metadata revealed. Identity information — an author or creator name — turned up in 13,166 of them, 33%. The software that produced the file showed up in 30,155, 76%. That study isn't about academic submissions specifically; it's a much larger, independently measured sample of ordinary PDFs, published by organizations that had every reason to be careful. The point it establishes still applies directly here: Nature's "usually added automatically" isn't a manuscript-specific quirk, it's how document software behaves by default, at a measured, large scale, across an entirely different population of files.

"Sanitized" doesn't always mean gone

The same study looked at what happened when an agency did attempt to clean a file before publishing it, and found the fix often didn't do what it looked like it did: 65% of the files that had gone through some sanitization step still contained recoverable sensitive data. For files run through exiftool specifically, the paper explains exactly why in its own words: "Metadata are stored in a separate object within a PDF file and exiftool only removes the reference to this metadata object in the file. Hence, it is still possible to access this object." In other words, a tool can make a field read empty when you check it and still leave the actual bytes sitting in the file, recoverable by anyone who looks at the raw structure instead of trusting the read-back. It's the gap between "the property panel says blank" and "the string is actually gone from the file you're about to upload."

What NearScrub actually clears for a manuscript

For a PDF manuscript, NearScrub deletes all eight Info-dictionary keys — Title, Author, Subject, Keywords, Creator, Producer, CreationDate, ModDate — and removes the XMP metadata stream when one is present, all in the browser tab itself. For a .docx some venues still accept directly, it blanks docProps/core.xml, app.xml, and custom.xml in one pass. It also covers something that's easy to forget is a separate file: a figure that started life as a phone photo or a screenshot, saved as a standalone JPEG or PNG rather than embedded losslessly from a vector source, can carry its own EXIF/GPS, XMP, or IPTC data — a camera or device name, a timestamp, occasionally a location — entirely independent of whatever the manuscript file's own properties say. NearScrub strips that from JPEG and PNG figures the same way it does from the manuscript itself. And because none of this requires uploading anything to perform the scrub, the step that's supposed to reduce what a stranger can learn about you doesn't itself become a second place the file passes through before it reaches the venue you're actually submitting to.

What it doesn't reach

It's worth being precise about the boundary. NearScrub clears property fields, not the document's visible content — a name that's still typed into an acknowledgments paragraph or a figure caption is a text edit, not a metadata one, and stays exactly as present as you left it. It doesn't resolve Word's tracked changes or delete its comments either; those live in word/document.xml and comments.xml, separate parts of the same .docx archive that clearing docProps never reaches, so accepting or rejecting changes and removing comments in Word's own Review tab has to happen first. And it only reads the formats it actually supports — JPEG, PNG, PDF, and the OOXML Office formats — so an older .doc, an .rtf, or a raw LaTeX source tree isn't something it can process at all. What it's built for is the specific, well-documented gap both sources above point at: the fields nobody typed and nobody asked the file to fill in, that a checklist can tell you to check for but that only a tool built to actually delete them — not just hide them from the properties panel — reliably closes.