GDPR: when file metadata is personal data

If you work with documents, photos or audio files, you are probably processing personal data — often without noticing. The GDPR does not only cover databases and CRM entries. It covers every piece of information that relates to an identifiable person, wherever it is stored.

Metadata is personal data

Article 4 of the GDPR defines personal data broadly: any information relating to an identified or identifiable natural person. That includes:

• an author name in a PDF or Word file,
• a GPS position in a photo,
• a device serial number,
• an email address in a document's properties,
• a timestamp combined with other identifiers.

Even a file that "only" contains a name and a date can be personal data if it can be linked to a person. In a corporate context, the link is often trivial: the document owner is a known employee.

Fig. 01How a file becomes personal data

1. 01File

   the content you meant to share

   →↓
2. 02Metadata

   author, GPS, device, timestamps

   →↓
3. 03Identifier

   points to a natural person

   →↓
4. 04Personal data

   GDPR obligations apply

Typical situations at work

Sharing documents with clients. Contracts, offers and reports often carry the author, the company name, the internal file path and the revision history. This exposes internal structures and personal names to every recipient.

Publishing photos. Marketing teams post photos with GPS data, which can reveal customer locations or the homes of employees.

Publishing job ads or press material. Images from stock libraries sometimes contain the photographer's private contact data.

Support tickets. Screenshots and logs may include metadata that identifies the customer.

Data minimization is the principle

The GDPR's data minimization principle (Article 5) says: collect and process only what you need. Applied to files, this means: if a file is shared for its content, its metadata is usually not needed. Removing it is not just allowed — it is good practice.

A practical checklist:

1. Define what must stay. Some metadata is required: accessibility data, digital signatures, or legally mandated timestamps.
2. Strip the rest. Use a metadata cleaner before publishing or sharing.
3. Verify the result. Re-analyze the cleaned file and keep proof of what was removed.
4. Document the process. A short internal guideline ("files are cleaned before external sharing") makes audits much easier.

Fig. 02Minimization, field by field

• ✓Accessibility metadatarequired to use the documentkeep
• ✓Digital signaturesneeded to verify authenticitykeep
• ✓Legally required timestampse.g. invoice dateskeep
• ✕Author / last modified bynames individualsstrip
• ✕GPS coordinatesgives away exact locationsstrip
• ✕Device serial numbersa persistent fingerprintstrip
• ✕Internal file pathsexposes team and server namesstrip

Retention also applies to files

Metadata is not the only issue. If you store scan reports or uploaded files, retention rules apply. ShredHub's own approach: files never leave your device; only the metadata report is stored, and only if you explicitly opt in. Free accounts keep history for seven days, Pro accounts until you delete it.

What ShredHub does for you

• Analysis and cleaning run locally in your browser. There is no upload endpoint — a verifiable design decision, not just a promise.
• Reports are opt-in. You decide whether a scan is stored.
• Cleaning is verifiable: the cleaned file is re-analyzed and shown with a verified-clean status.

Fig. 03Where the data is processed

Your browserlocal

• Analysis in a Web Worker
• Cleaning of the file
• Metadata report

Upload endpointnot used

• Does not exist
• No file storage
• Nothing to breach

The file never crosses the network.

Takeaway

Metadata handling is a small but concrete part of GDPR compliance. It is easy to implement, easy to verify, and it closes a gap that most organizations have not looked at yet.