Is photo metadata personal data under privacy law?

One note before anything else: this is general information about how published definitions are written, not legal advice, and nothing here is specific to your organisation or your jurisdiction. Thresholds, exemptions, regulators and enforcement all vary, and the quoted definitions below are from the EU GDPR text and a California state description because those are the ones whose wording is public and stable enough to quote. If a decision has real consequences, get advice from somebody qualified to give it.

Why this is a different problem from the rest of the site

A privacy page normally reasons about harm: if this coordinate escapes, somebody might find my house. A compliance question reasons about duty, and duty does not track harm neatly. You can hold metadata that will never hurt anyone and still hold it unlawfully, because you had no reason to keep it. You can also strip metadata with the best intentions and create a problem, because somebody was entitled to receive it or you were required to preserve it. The second half of that sentence is why "just remove everything" is a weaker answer here than anywhere else on this site.

The other shift is whose data it is. On a personal page, the metadata is yours. In an organisation, a single JPEG can carry data relating to at least three people: the subject in the frame, the photographer whose camera serial and author field are embedded, and whoever was tagged by name in the photo-library software the file passed through. You can be accountable for all of it while having created none of it.

What the definitions actually say

The EU and UK definition names location data explicitly. GDPR Article 4(1) defines personal data as "any information relating to an identified or identifiable natural person", and says that an identifiable person "is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person". You do not have to argue your way to including GPS tags; location data is in the list. The real work is done by the words relating to. Coordinates on a photograph of an empty field may relate to no one. The same coordinates on a photograph of a named child, taken at their home address, relate to that child very directly, and the file now records where a specific person was at a specific minute.

Indirect identification is enough. This is the part people miss. A camera body serial number identifies nobody on its own, and identifies the owner immediately once you hold two files and a purchase record, or once the same serial appears on a photo with a name attached. The definition covers identification "directly or indirectly", so the question is not whether a field names someone but whether it can be linked to someone with means reasonably available.

California frames it broadly too. The California Attorney General's description of the state's consumer privacy law says personal information is information that identifies, relates to, or could reasonably be linked with you or your household, and lists geolocation data among the examples alongside names, email addresses and browsing history. A narrower subset is treated as sensitive personal information, and precise geolocation appears in that subset, with an associated consumer right to direct a business to limit its use and disclosure. Whether that law applies to your organisation at all depends on thresholds that are not metadata questions — do not read a definition as a conclusion that you are covered, or that you are not.

Face tags are personal data without being automatically biometric. Article 4(14) defines biometric data as "personal data resulting from specific technical processing relating to the physical, physiological or behavioural characteristics of a natural person, which allow or confirm the unique identification of that natural person, such as facial images or dactyloscopic data". Recital 51 then draws the line that keeps ordinary photo collections out of the strictest category: "The processing of photographs should not systematically be considered to be processing of special categories of personal data as they are covered by the definition of biometric data only when processed through a specific technical means allowing the unique identification or authentication of a natural person." In plain terms, a name typed into a region tag by a photo app is personal data about that person; a face template generated to match them against a gallery is a different and heavier thing. Some jurisdictions regulate biometric identifiers through dedicated statutes with their own consent rules, so that is a question for local advice rather than inference.

The four duties that embedded metadata actually touches

1. Minimisation — the strongest argument for stripping on arrival. Article 5(1)(c) requires that personal data be "adequate, relevant and limited to what is necessary in relation to the purposes for which they are processed". Ask what purpose is served by retaining the lens model, the shutter count, the editing history and the coordinates of a volunteer's kitchen. There usually is not one. If you cannot name the purpose, the field is hard to defend, and the cheapest fix is to never store it: strip the copy you keep, at the moment you take delivery of it.
2. Access — the duty that points the other way. Article 15(3) says the controller "shall provide a copy of the personal data undergoing processing", in a commonly used electronic form where the request arrives electronically. Metadata you still hold about the person asking is part of what you hold. The failure mode is subtle: your system answers with a web-sized re-encode that has no tag layer, which looks complete and is not, because the original with the full EXIF is still in storage.
3. Erasure — and everything a strip does not reach. Article 17 gives a right to erasure where, among other grounds, "the personal data are no longer necessary in relation to the purposes for which they were collected or otherwise processed". Honouring that for a photo means finding the derivatives: resized variants, thumbnails, the CDN cache, object-storage versions, nightly backups, the moderation queue, and any log or database column where you extracted the metadata into text. Stripping the master does nothing to a JSON blob in a table. The engineering side of that problem is covered in handling metadata in photos your users upload.
4. Transparency — does your notice match your files? Most privacy notices written by small organisations list names, emails and phone numbers. Very few mention that submitted photographs may contain device identifiers and precise locations which you retain. You can fix that by amending the notice, or by making it true: stop keeping the metadata and the sentence becomes unnecessary. The second is less work and ages better.

A workflow that keeps this boring

1. Decide in advance whether you need any embedded metadata. Say the purpose out loud. Verification of a damage claim, provenance for a news photo and a research dataset are real reasons. A gallery page, a newsletter, a staff directory and a listing almost never are.
2. Strip the stored copy, not the displayed one. Cleaning images on the way out while keeping rich masters leaves you holding everything you were trying not to hold.
3. If you must retain metadata, separate it deliberately. Keep it with a named purpose, a named owner and a retention clock, rather than as an accident of the file format.
4. Write down what you keep and where it lands. One page naming each copy — original, variants, thumbnails, backups, logs — is what makes an access or erasure request answerable in minutes instead of guesswork.
5. Train the humans, because they bypass the pipeline. The committee member who forwards twenty photos from their phone by email has routed around every control you built. Tell people where to send images and why.
6. Quarantine anything that has become evidence. Complaints, incidents, insurance and disputes can create an obligation to preserve a file exactly as received. Copy it somewhere outside the routine cleaning path and leave it alone.
7. Handle photos of third parties on their own terms. The person who sent you a picture is often not the person it is about, which is the subject of photo metadata when the photo is of someone else.

Common mistakes and misconceptions

"Metadata is technical data, not personal data." The GDPR definition lists location data as an example of an identifier, and allows indirect identification. Technical origin has never been the test.

"We have consent for the photograph, so the metadata is covered." Consent is tied to a purpose you described. A parent agreeing to a team photo on a club website has not agreed to the club retaining the coordinates of where the photo was taken for an indefinite period.

"The photographer owns the file, so it is their responsibility." Copyright and data protection are separate frames that both apply. Ownership of the image does not determine who is accountable for personal data inside it, and the data in those fields may relate to the subject rather than the photographer.

"We are too small for any of this." Some regimes have revenue or volume thresholds and some have very few exemptions, and the small-organisation carve-outs that do exist are usually narrower than people assume. Check the rules that actually apply to you instead of reasoning from size.

"We stripped the metadata, so we are compliant." The photograph is still personal data. Stripping addresses one principle for one layer of one file, which is worth doing and is not a programme.

"Deleting the photo deletes the metadata." Only if deletion reached every copy. Thumbnails, caches, backups and extracted database fields routinely survive the deletion of the file they came from.

"Nobody will ever ask." Perhaps not. The cost of being ready is a one-page record and a strip step at intake; the cost of not being ready arrives at the worst possible moment, usually attached to a complaint from somebody who is already unhappy.

Where this site's tool fits, and where it does not

Plainly, because this page is about not overestimating a cleaning step. MetadataWipe accepts image/jpeg and image/png only, one file at a time. It decodes the image, draws it to a canvas at the original pixel dimensions and exports a new file from that canvas — a fresh lossy encode for JPEG at a quality fixed in the code, a fresh PNG otherwise — appends -metadatawipe to the filename and leaves your original untouched. All of that runs inside the page on your own device; nothing is sent anywhere, which is also why there is no server-side record of what you cleaned.

That makes it useful for the last metre: a handful of images going into a newsletter, a listing, a notice board or a gallery page, cleaned before they enter your systems. It is not a compliance tool. It has no audit trail to show a regulator, no field-level control that would let you keep a credit line and drop the coordinates, no batch mode for a four-year photo archive, and no reach into your database, your backups or the variants your CMS generated last year. Its built-in check reports presence rather than values — for a JPEG it looks near the start of the file for an APP1 segment carrying the Exif identifier and for the literal text GPS; for a PNG it walks chunk types looking for eXIf, tEXt, iTXt, zTXt, tIME and iCCP — so use a full metadata reader when you need to know what a field actually says before you decide whether you are allowed to keep it. Anything systematic belongs in your intake pipeline with a library that can log what it did.

Related guides

See also:

• Handling metadata in photos your users upload
• Photo metadata when the photo is of someone else