The information you did not know you were sending
Every PDF carries a block of metadata describing the file rather than its contents: a title, an author, a subject, keywords, the application that created it, the application that converted it, and timestamps for creation and modification. Most of it is filled in automatically, from your operating system account and your software's licence details, without anybody choosing to include it.
The consequences are routine and occasionally serious. A CV sent to an employer names the person whose computer produced it, which is awkward if that is not you. A document circulated as coming from an organisation names the individual who wrote it. A file presented as freshly prepared carries a creation date from three years ago. A tender submission reveals which template — and sometimes which competitor's document — it was built from.
None of this is visible when you read the document. All of it is visible to anyone who opens the file's properties, which takes two clicks in any PDF reader.
What is worth removing, and what is worth keeping
For anything leaving your organisation, the author, creator and producer fields are the ones that matter most, because they identify a person and a piece of software. Title and subject are worth checking too: PDF titles frequently retain the original filename, which can be far more revealing than the document's own heading.
Timestamps are a judgement call. They are useful for your own records and occasionally required — some legal and compliance processes expect a creation date. But they also reveal working patterns, and a document created at two in the morning three days after it was requested tells a story you may not want told.
Keeping some metadata is entirely legitimate. A published report benefits from a proper title and author, because it helps people cite and find it. The goal is that the metadata says what you intended it to say, rather than whatever your software happened to write.
Where metadata hides beyond the document properties
Cleaning the main properties block is necessary and not always sufficient. Images embedded in a PDF can carry their own EXIF data, which on a photograph taken with a phone may include the precise GPS coordinates where it was taken, along with the device model and the exact time.
For a photographed document that is a real disclosure — the location of your home or office, attached to a file you emailed to a stranger. If the PDF was built from phone photographs and the destination is public, strip the images' metadata before assembling the document, not just afterwards.
It is also worth remembering the filename itself. It travels with the file, it is not part of the metadata you can clean here, and "salary-review-final-v3-DONOTSEND.pdf" has ended more than one negotiation early.
When to clean, and building it into a habit
The moment to clean metadata is immediately before a document leaves your control, not when you create it. Editing tends to rewrite metadata anyway, so cleaning early and then making changes simply reinstates what you removed.
It is worth making it routine for a few categories rather than deciding case by case: anything published on a website, anything sent to a party you are negotiating against, anything submitted anonymously, and any document assembled from a template belonging to someone else. Those four cover the overwhelming majority of situations where metadata causes an actual problem.
For everything else, a quick look at the document properties before sending is usually enough. The point is not paranoia — it is knowing what the file says about you, so that what it says is what you chose.