2026-09-07

Saving it as a PDF doesn't remove the metadata — it writes new metadata

There is one step in almost everyone's send-a-document routine that gets quietly treated as a cleaning step: "I'll just save it as a PDF." It certainly feels like one. The tracked changes stop showing, the file stops being editable, and the thing that leaves your computer looks nothing like the thing you were working on. What actually happens is close to the opposite. Exporting to PDF carries most of your document's properties across, and then the exporting software writes a fresh set of fields describing itself and the moment you clicked the button. Converting a file does not end its metadata history. It appends to it.

The properties come along, and it is a checkbox

Start with the half people are most surprised by: the author line in your docx does not stay behind. Microsoft documents the control in a single sentence on its Save or convert to PDF or XPS in Office desktop apps page — "To include document properties in the PDF, make sure Document properties is selected." That switch lives behind the Options button in the Save As dialog, which is not somewhere most people go on the way to emailing a proposal.

The consequence is worth stating flatly. The dc:creator and cp:lastModifiedBy values sitting in your Word file's docProps/core.xml — which may be your name, may be a colleague's, may be the name of whoever's template you started from — and the <Company> line in docProps/app.xml are candidates for the PDF you send out. Saving as PDF is not a filter. It is a copy with a checkbox in front of it, and the only way to know which way that checkbox is set on your machine is to open the dialog and look.

Then the exporter signs its own work

The second half is the part no checkbox governs. A PDF carries a document information dictionary whose entries include Title, Author, Subject, Keywords, Creator, Producer, CreationDate and ModDate (ISO 32000-1) — and most modern files also carry an XMP packet holding the same information in a different shape. Two of those keys exist specifically to describe tooling: one names the application the document came from, the other names the software that produced the PDF. Two more are timestamps. None of them are copied from your document, because they are not about your document. They are written at export time, by the thing doing the exporting, about itself.

An easy way to see the split is to look at a file produced by people whose job is precisely this topic. The UK Information Commissioner's Office publishes a guidance document called How to disclose information safely. Download the PDF the ICO serves and read its XMP packet (we checked the copy served on 7 September 2026) and you find dc:title and dc:creator both empty — someone cleared the title and the author, which is the right thing to do — sitting beside xmp:CreatorTool "Acrobat PDFMaker 17 for Word", pdf:Producer "Adobe PDF Library 15.0", xmp:CreateDate 2018-06-01T15:35:52+01:00 and xmp:ModifyDate 2020-12-24T08:46:58Z.

Nothing in that is a privacy incident, and it is not offered as a gotcha — no person is named and no personal data is exposed. It is offered because it is such a clean demonstration of the mechanism: the fields a careful person clears and the fields an export writes are different fields, written at different moments, by different software. Clearing the first set does nothing to the second. What survives is a description of the toolchain — authored in Word, converted with Acrobat PDFMaker, produced by a named Adobe library, first built on a Friday afternoon in June 2018, last touched on 24 December 2020. That is a small, quiet paragraph about an organisation's software estate and someone's working hours, and it is in a file about disclosing information safely.

Every stage that writes the file writes metadata about itself. Clearing the fields in the middle of that chain buys you nothing if another stage follows.

Timestamps are evidence, not trivia

It is tempting to file creation and modification dates under harmless. Courts do not. In Lake v. City of Phoenix, decided by the Arizona Supreme Court on 29 October 2009, a Phoenix police officer requested his supervisor's notes about his job performance, received them on paper, and suspected "that they had been backdated when prepared on a computer." He asked for the electronic originals with their metadata; the city refused, arguing metadata was not part of the public record; the trial court and the court of appeals agreed with the city. The Supreme Court reversed, and put the reason in one sentence: "When a public officer uses a computer to make a public record, the metadata forms part of the document as much as the words on the page."

That case is US public-records law and does not transplant directly anywhere else, but the underlying observation does. A CreationDate is not a decoration; it is a claim about when the file came into being, and other people can and do read it as one. Which cuts in a direction this post has to be honest about: there are documents you must not strip. If a file is subject to a litigation hold, a discovery obligation, a records-retention rule or an audit, removing its metadata is not privacy hygiene — it is destroying evidence, and it can be sanctionable. The advice here is about documents you are free to send as you choose: a CV, a portfolio, a quote, a photo, a form for a service that has no business knowing which laptop you filled it in on. It is not about documents somebody has a legal right to receive intact.

Which is why cleaning has to be the last thing you do

Put the two halves together and the practical rule falls out on its own. Metadata is written by whatever writes the file, so the cleanest file in the world stops being clean the moment something else saves it. The steps that quietly re-stamp a document are the ordinary ones:

exporting to PDF again after a small edit;
running the file through a "compress PDF" or "merge PDF" tool;
printing to PDF — the print pipeline is itself a producer;
opening the document in a cloud editor and downloading it back;
adding a signature, a stamp or a page number with a PDF editor;
converting to another format and back.

None of those are misuse. They are what people do to files. The consequence is just that metadata removal is not a state you put a document into and then forget about — it is a step with a position in a sequence, and its position is last, immediately before the file leaves your machine. If you scrub and then do anything else, scrub again.

What NearScrub does here, and what it does not

NearScrub runs entirely in the browser tab — the file is never uploaded — and on a PDF it does exactly two things: it deletes the eight document-information keys listed above, and it deletes the XMP metadata stream if one is present. On a JPEG it drops the EXIF/GPS, XMP and IPTC segments and image comments. On a PNG it drops the text and time chunks. On a docx, xlsx or pptx it blanks three parts — docProps/core.xml, docProps/app.xml and docProps/custom.xml — and re-zips the archive.

That list is also the boundary, and the honest version of it is longer than the feature list:

It cannot stop your next export. This is the whole point of the post. Nothing a scrubber does survives the next piece of software that writes the file.
It does not touch page content. A black rectangle drawn over a paragraph stays a drawn rectangle, and the text underneath stays selectable and copyable. Annotations, form fields, embedded attachments, optional-content layers and the OCR text layer behind a scan are all left as they are. Nor does clearing metadata do anything about the leakage of redacted words through the positions of the surrounding glyphs.
In Office files it only clears the three docProps parts. Tracked changes, comments, speaker notes, hidden rows and columns, and embedded objects live elsewhere in the same archive and are untouched — resolve those in Word or Excel first.
ODF files are a weaker case than the file picker suggests. An .odt, .ods or .odp is accepted, but OpenDocument keeps its properties in meta.xml, not in docProps/, so what NearScrub does to those files is re-zip them. Clear their properties in LibreOffice instead.
The output is a re-serialisation, not surgery. The PDF is re-saved and the Office archive is re-compressed, so the bytes and any checksum differ from the original. If a recipient needs to verify a hash, scrub before hashing, not after.
Supported types are JPEG, PNG, PDF and OOXML only. HEIC — the default camera format on modern iPhones — is not supported, and neither is video, TIFF, RAW, or Korean HWP/HWPX. An unsupported file is passed through unchanged rather than silently "cleaned".
It says nothing about what is visible. A street sign in the photo, a letterhead on the page, a client name in the body text: all still there, and all still readable.

Thirty seconds to check any of this yourself

You do not need a tool to test the claim at the top of this post. Take a document, export it to PDF, and open the result's properties — File → Properties in Acrobat, Tools → Show Inspector in macOS Preview, the document-properties panel in most browser PDF viewers. Look at what is in Author, Application and PDF Producer, and look at the Created timestamp. Then run the file through NearScrub, open the properties again, and confirm the fields are gone. Then — this is the part that matters — put the cleaned file through whatever step you were planning to do next, a compressor or a signing tool or a re-export, and open the properties one more time. Whatever is back in there is what your recipient would have received.