The short version

PDFs store an author name, a title, the creating software and timestamps in places no reader displays while you are reading.

The author field usually holds a real name or a corporate username, and the title is often whatever the source document was called, which can be considerably more revealing than the filename you chose.

Open the document properties of almost any PDF you have received and you will find a name. Sometimes it is a person, sometimes an account like jsmith, occasionally a machine name that identifies an organisation. Nobody put it there deliberately. The software that created the file filled it in from the operating system.

What is actually stored

Metadata lives in two places in a PDF, and tools that clean one sometimes leave the other.

AnatomyWhere metadata sits
Form field layervalues typed into fieldsAnnotation layercomments, highlights, signaturesPage contenttext and images, always drawnreader draws
None of it is page content, which is why it never appears while you are reading.

The document information dictionary is the older mechanism: a small set of named fields holding title, author, subject, keywords, creator, producer and two timestamps. XMP metadata is the newer one, an embedded block that often duplicates those fields and can carry a great deal more, including editing history from design software.

Fields you will typically findDocument information
  • AuthorA name or username
  • TitleOriginal document name
  • CreatorApplication it came from
  • ProducerLibrary that wrote the PDF
  • CreationDateWhen it was first made
  • ModDateWhen it was last changed
Title is the field that surprises people
It is not the filename. It is whatever the source document was called when it was exported, which is frequently something like Draft 4 client proposal REVISED final. Renaming the PDF afterwards changes nothing, because the title lives inside the file and the filename lives outside it.

How to see it

Every mainstream reader exposes this, usually under document properties or information in the file menu. It takes about ten seconds and is worth doing on a document you have already sent, because that is the fastest way to understand what you have been sharing.

1

Open document properties

In most readers this is under the File menu, named Properties, Document Properties or Get Info depending on the application.

2

Read the description tab

Author, title, subject, keywords, and the application and library that produced the file, along with creation and modification times.

3

Look for an XMP or advanced view

Some readers show the raw XMP block separately. It frequently contains more than the summary fields, including identifiers that link revisions of the same document together.

When it matters

For a restaurant menu, not at all. For several common situations, quite a lot, and the pattern is that metadata reveals context the document itself was written to avoid revealing.

Where it causes problemsSituation and exposure
  • Anonymous submissionsAuthor names you
  • Blind peer reviewAuthor defeats the blinding
  • WhistleblowingUsername and machine identify you
  • Competitive tendersTimestamps show preparation time
  • Legal disclosureModification dates imply editing
  • Templated client workTitle names the other client
The reused template problem
Producing a client proposal by editing the last one is normal practice, and it carries the previous client's name in the title field into the new document. This is one of the most common genuine embarrassments caused by metadata, and it is entirely invisible to everyone involved until someone opens the properties.

Removing it

Stripping metadata rewrites the document without the information fields. The pages are unaffected, because none of this data is part of what gets drawn.

Effect on page content
None

Metadata sits in the file structure, not in the content streams. Nothing visible changes.

Effect on file size
Minimal

A few kilobytes at most, unless an XMP block has grown unusually large.

Fields cleared
All of them

Both the information dictionary and the XMP block need clearing, not just one.

Strip last, after every other edit
Editing tools write their own metadata as they work. Compress a document after stripping it and the compressor stamps its own producer line back in. Make metadata removal the final step before sending, and check it afterwards rather than assuming.

What else travels invisibly

Metadata fields are the well-known part. A few other things ride along in the file and none of them show on the page.

Cleared by stripping metadata

The named fields

  • Author, title, subject and keywords
  • Creator and producer application names
  • Creation and modification timestamps
  • XMP block contents, if the tool handles it
Needs handling separately

Everything else

  • Comments and annotations left in the margins
  • Bookmarks whose names describe removed sections
  • Attached files embedded inside the PDF
  • Earlier revisions kept by incremental saving
Incremental saves keep your edits
A PDF updated by appending changes rather than rewriting keeps its earlier states inside the same file. Metadata stripping that only clears the current revision can leave the old author name recoverable in a previous one. Saving a fresh complete copy removes the history along with the fields.

Making it routine

The practical difficulty is that metadata is invisible, so it is never the thing you remember to check. The fix is to attach the check to something you already do.

Three points where it is worth a look

Anything leaving the organisation. Proposals, reports, submissions. Ten seconds in document properties before it attaches to an email.

Anything built from a template. The previous client's name in the title field is the single most common leak of this kind.

Anything meant to be anonymous. Blind review, anonymous feedback, confidential submissions. Metadata undoes anonymity more often than the content does.

See and clear what a PDF says about itself

Both the document information dictionary and the XMP block, without uploading the file.

Open Metadata Remover

Common questions

What is in there and what it gives away.

01What metadata does a PDF contain?

Title, author, subject, keywords, the creating application, the library that wrote the file, and creation and modification timestamps. Many files also carry an XMP block duplicating those fields and sometimes adding editing history from design software.

02Where does the author name come from?

The creating application usually takes it from your operating system account or from the source document's properties. Nobody types it in deliberately, which is why it so often contains a real name or a corporate username.

03Is the title the same as the filename?

No, and this catches people out. The title is stored inside the file and reflects what the source document was called when it was exported. Renaming the PDF changes the filename only, leaving the internal title exactly as it was.

04Does removing metadata change how the document looks?

Not at all. Metadata lives in the file structure rather than in the page content streams, so stripping it leaves every page pixel-identical. The file may shrink by a few kilobytes.

05When should I strip metadata?

Last, after every other edit. Compression, merging and editing tools all write their own metadata as they work, so a document stripped early picks up new fields before it is sent. Make it the final step and verify afterwards.

06Does stripping metadata remove comments and attachments?

Usually not. Annotations, bookmarks and embedded file attachments are separate structures from the metadata fields, so they need removing in their own right. Check for them independently before sending anything sensitive.