PDF metadata — the hidden fields recording your name, your manager's name, your software, and your editing timeline — creates different risks depending on your profession. A lawyer risks privilege exposure. An HR professional risks personal data violations. A freelancer risks pricing transparency. A journalist risks source proximity. This guide covers each profession separately, with real ExifTool examples and specific removal workflows.
The same PDF file. Sent to four different recipients, by four different professionals. The document itself is identical. The metadata consequences are completely different.
That's what most metadata guides miss. They explain what metadata is — which fields exist, how to remove them — but treat the risk as uniform. It isn't. The Author field containing "Sarah Chen" is a minor inconvenience when a freelancer sends a proposal. It's a potential privilege problem when a solicitor shares a draft agreement. It's a GDPR compliance failure when an HR team sends an offer letter. It's an operational security issue when a journalist is working a sensitive story.
This guide treats the four professions separately, with the specificity each deserves. If you only need one section, use the profession pills above to jump directly.
#1. Legal professionals
A US litigation firm produced documents in response to an eDiscovery request. The documents themselves were properly reviewed and redacted. But the metadata was not stripped. The produced PDFs contained Keywords fields populated by the firm's document management system — fields that included internal matter classifications, privilege designations, and attorney assignment codes. The opposing party's e-discovery vendor extracted these automatically. The privilege log became a map.
This is not a hypothetical. Metadata exposure in legal document production is a documented, recurring problem. The ABA has addressed it directly.
ABA Formal Opinion 11-460 (Duty When Inadvertently Receiving Metadata) and ABA Model Rule 1.6 (Confidentiality of Information) together establish that lawyers have an obligation to use reasonable care to prevent inadvertent disclosure of client information — including metadata embedded in documents shared externally. The obligation applies both to documents sent to opposing parties and to documents sent to clients, regulators, or courts.
The metadata fields that carry the highest risk in legal practice are not always the obvious ones:
KeywordsAuthorManagerModDateTitleRevisionNumberThe document management system (iManage, NetDocuments, Worldox) is the primary source of metadata contamination in law firms. These systems automatically write matter numbers, client codes, document types, and status markers into the Keywords field of every document they manage. When an attorney exports a document to PDF for sharing, these internal codes travel with it.
Manager : David Clarke ← supervising partner
Keywords : PRIV-AC, Matter:C2847-001, SETTLEMENT, draft-v7 ← privilege designation + matter code
Title : Settlement Agreement — Acme Corp v. XYZ Ltd
Create Date : 2026:09:01 09:12:44+01:00
Modify Date : 2026:09:28 22:43:11+01:00 ← 27 days editing visible
Revision Number : 89 ← extensive negotiation history
Under Federal Rules of Civil Procedure Rule 26, metadata is discoverable as part of electronically stored information (ESI). The obligation to produce metadata in discovery is well-established. What's less understood is the risk of inadvertently producing privileged metadata — internal classifications that the firm never intended to disclose — when sharing documents outside the formal production process.
Strip metadata from any document before sharing externally — to clients, to opposing counsel, to courts, and to regulators. The stripping step should be part of the file-closing workflow, not an afterthought. For produced documents in discovery, coordinate with your e-discovery vendor on metadata handling requirements specified in the ESI protocol. Do not assume that redacting document content also strips metadata — these are separate operations requiring separate tools.
Strip metadata before it leaves your firm
Browser-only. Nothing uploaded. Removes DMS keywords, attorney names, and privilege markers.
#2. HR and people teams
For the full guide, see PDF metadata in HR and employment documents.
An HR manager at a mid-size UK employer sends a job offer letter to a successful candidate. The letter is properly formatted — salary, start date, benefits, reporting line. What the HR manager doesn't check is the metadata. The Author field contains her full name. The Manager field contains the Head of HR's name. The Keywords field, automatically populated by SharePoint, contains internal compensation band codes and the requisition number.
The candidate, who happened to work previously at a technology company with a security-conscious culture, opens the file in Acrobat Reader, goes to File → Properties, and sees the compensation band code. They recognise the internal grading system from their previous employer, which uses the same HR software. They now have information about the firm's salary structure that was not intended for disclosure.
The Author and Manager fields in HR-generated PDFs contain employees' full names — personal data under GDPR Article 4(1) and UK GDPR. Sharing these fields with external parties (candidates, contractors, former employees) without a lawful basis and in violation of the data minimisation principle (Article 5(1)(c)) is a personal data breach. The Information Commissioner's Office (ICO) has published guidance specifically noting that organisations should check documents for personal data in metadata fields before external sharing.
The RevisionNumber field is particularly revealing in HR contexts. A termination letter that was revised 23 times before being sent tells the receiving employee — or their solicitor — that the letter was extensively negotiated internally. That information, while not technically privileged, creates an impression of uncertainty and may encourage legal challenge.
For teams working in Microsoft 365 environments, SharePoint document libraries automatically write metadata into the Keywords and Subject fields of Office documents. When those documents are exported to PDF, the SharePoint metadata travels with them. HR teams should check both the source document properties in Word (File → Info → Properties) and the exported PDF.
Before sending any HR document externally — to a candidate, a former employee, an employment tribunal, a reference recipient, or an external payroll bureau — pass the PDF through a metadata check. The Author, Manager, and Keywords fields should always be stripped. RevisionNumber and timestamps are worth removing for sensitive documents like termination letters and settlement agreements. For teams processing high volumes, ExifTool's batch processing (exiftool -all= *.pdf) covers an entire folder in one command.
#3. Freelancers and independent consultants
For the full guide, see why freelancers must remove PDF metadata from proposals and contracts.
The risks for freelancers are less about legal liability and more about negotiation position and professional perception. But they're no less real.
A UX designer sends a proposal to a prospective client. The rate is £850/day. The covering note says the proposal was prepared specifically for this project. The client opens the PDF properties out of curiosity. The Creator field says "Canva." The CreationDate is from 2022. The ModDate is from this morning — 07:43, two hours before the proposal landed in their inbox.
Three pieces of information the designer didn't choose to share: the proposal was built on a template created three years ago, it was prepared using a free design tool rather than premium software, and it was finished in a last-minute session this morning. None of this makes the proposal bad. All of it affects how the client reads the £850/day rate.
The RevisionNumber field records how many times the source document was saved — including auto-saves. A proposal described as "bespoke" with a RevisionNumber of 3 looks genuinely fresh. The same proposal with a RevisionNumber of 67 suggests extensive reworking of an existing template. The xmpMM:DocumentID field persists across documents derived from the same source — meaning two proposals sent to different clients can be linked by a recipient who knows to look.
Creator : Canva ← free tool — may contradict premium pricing
Create Date : 2022:08:14 11:22:08+00:00 ← template created 4 years ago
Modify Date : 2026:10:05 07:43:11+00:00 ← finished 2 hours before sending
XMP:DocumentID : uuid:f3a2c1b4-8d7e-... ← links to template used for other clients
Revision Number : 67 ← heavily adapted existing document
Client confidentiality is the other dimension. A freelancer who includes a previous client's information in their proposal template — even inadvertently, as embedded text in a template layer — and then shares that template with a new client has a confidentiality problem. Metadata is one vector; embedded hidden content is another. Both require dedicated sanitisation tools, not just visual review.
For consultants who charge on a per-project rather than per-day basis, the RevisionNumber can be particularly revealing. If a "strategy document" that bills 40 hours has a RevisionNumber of 4, it suggests very little iteration. If a "quick overview" has a RevisionNumber of 89, it suggests significantly more work than the document implies — which cuts both ways.
Strip metadata from every document before it leaves your hands — proposals, contracts, invoices, deliverables. For proposals specifically, use a metadata check as the final step before sending, not the final step in document creation. Create templates with metadata stripped, and re-strip before each send. Our complete guide on removing metadata from PDFs covers every method including how to verify the XMP stream was fully cleared.
#4. Journalists and media professionals
For the full guide, see how investigative journalists use PDF metadata to verify documents.
In 2017, a Reality Winner leaked a classified NSA document to The Intercept. The outlet, in the process of verifying the document's authenticity, sent a photograph of the printed document to the NSA for comment. The photograph revealed printer tracking dots — microscopic yellow dots embedded by colour laser printers that encode the printer serial number and print date. The NSA used these to identify the source printer, which was checked out to Winner. She was arrested within days of the story's publication.
That incident involved printer metadata rather than PDF metadata. But the underlying dynamic is identical: document handling created a metadata trail that exposed a source. For journalists, metadata risks operate at two distinct levels.
Risk 1 — Metadata you create. When a journalist edits, annotates, or processes a document, their metadata is added to it. Author field, modification timestamps, and software fingerprint can identify the journalist who handled the document — relevant when a processed version circulates publicly or is submitted to authorities. Risk 2 — Metadata in documents received from sources. PDFs received from sources may carry metadata identifying the source — their name in the Author field, their employer in the Company field, or their software environment in the Creator field. Publishing or forwarding the raw received document may inadvertently expose the source.
Most newsrooms now have established protocols for the second risk — digital security desks, SecureDrop systems, and document sanitisation workflows. The first risk is less consistently addressed.
For journalists working on sensitive stories, the SecureDrop whistleblowing platform is designed to receive documents without logging metadata about the source's connection. The Freedom of the Press Foundation maintains SecureDrop and publishes guidance on its technical operation. For journalists who cannot use SecureDrop, receiving documents via Signal (which strips metadata from files sent through its protocol) is a significantly better option than email.
For document verification — checking whether a received document has been altered, when it was created, and what software produced it — metadata analysis is itself a tool, not just a risk. Our guide on detecting PDF editing and tampering covers the forensic methodology journalists use to verify document authenticity.
Strip all metadata before embedding or linking any PDF document in a published article. The metadata in a document you publish is readable by any reader — including the subjects of your investigation, law enforcement, and hostile state actors. This applies equally to documents you've written and documents you've received. Strip both. The Tails operating system, which routes all traffic through Tor and runs from a USB drive leaving no traces on the host machine, is the most thorough approach for journalists working in high-risk environments. For everyday workflows, a dedicated metadata removal tool run on a secure machine is the minimum standard.
#5. Universal pre-send checklist — all professions
Regardless of profession, the same five verification steps protect you. The checklist below is interactive — mark each step as you complete it before sending any sensitive document.
#6. How metadata risk compares across professions
| Risk type | Lawyers | HR teams | Freelancers | Journalists |
|---|---|---|---|---|
| Personal data (GDPR) | ⚠ High — attorney names | ⛔ Critical — employee names | ⚠ Medium — freelancer name | ⚠ High — journalist identity |
| Privilege / confidentiality | ⛔ Critical — DMS keywords | ⚠ Medium — HR classifications | 🟢 Low — client info in templates | ⛔ Critical — source exposure |
| Commercial / negotiation | 🟢 Low | ⚠ Medium — salary bands | ⛔ Critical — pricing, tool choice | 🟢 Low |
| Regulatory obligation | ⛔ ABA Rule 1.6, FRCP 26 | ⛔ GDPR Art. 5(1)(c), ICO guidance | ⚠ GDPR if EU clients | ⚠ Shield laws, press freedom |
| Highest-risk field | Keywords (DMS codes) | Author + Manager (PII) | CreationDate + RevisionNum | Author on annotated docs |
| Primary tool recommendation | ExifTool + verification | FileIntel batch or ExifTool | FileIntel before each send | Tails OS + ExifTool for high-risk |
The common thread across all four professions: the metadata that creates the most risk is rarely the metadata you chose to include. It's the metadata your software, your document management system, or your operating system added without asking. Understanding which fields carry that automatic data — and building a verification step into your document workflow — is what separates professionals who manage this risk from those who discover it too late.
For a complete reference to every PDF metadata field and what each one contains, see our PDF metadata fields explained guide. For the technical removal workflow, see how to remove metadata from a PDF.
Strip metadata before your next document goes out
Author, Manager, Keywords, XMP stream — all removed. Free, browser-only, 10 seconds.
Frequently asked
exiftool -all= document.pdf followed by exiftool -XMP:all document.pdf to verify the XMP stream was cleared.This guide is for general informational purposes. It does not constitute legal advice, GDPR compliance advice, or information security guidance specific to your organisation. Regulatory obligations vary by jurisdiction, contract, and document type. Consult a qualified legal or compliance professional for advice specific to your situation. Tool limitations: no metadata removal tool can guarantee complete removal across all PDF versions and configurations — verify output independently for high-stakes documents.