When to Strip Image Metadata Instead of Adding It
Geo-tagging a storefront photo is good practice. Publishing a customer's house at rooftop precision because a phone recorded it is a data-protection incident. Which fields are safe to publish, which are not, and how to decide per image rather than per site.
Most writing about image metadata is about adding it. Write a description, embed a copyright string, attach GPS coordinates so a local business can state where it operates. That is sound advice, and it is one half of the subject.
The other half rarely gets written down: some metadata should be removed before publication, and the images where that is true are frequently the ones a business is keenest to publish. Completed work. Before-and-after shots. Anything photographed at a customer's address.
What is actually in the file
An unprocessed photograph from a modern phone carries considerably more than most people expect.
| Field group | Typical contents | Publication risk |
|---|---|---|
| GPS block | Latitude, longitude, altitude, GPS timestamp | High — resolves to a building |
| Date and time | Original capture time, timezone | Moderate — establishes presence |
| Device | Make, model, sometimes a serial number | Moderate — links images to one device |
| Camera settings | Exposure, aperture, ISO, lens | None |
| Author fields | Artist, copyright, description | None — you wrote them |
| Editing history | Software, edit timestamps | Low |
The GPS block is the one that matters. It is written by default on both major mobile platforms, it is precise enough to identify a specific address, and it is invisible in every ordinary viewing context. Nobody sees it in a browser, a gallery app or a CMS preview. It only appears when someone inspects the file, which almost nobody does — until someone does.
The scenario that catches good businesses
A technician finishes a job, photographs the result on their phone, and sends it to marketing. It goes on the site as proof of work. The customer is pleased to be featured.
That file now publishes the customer's home coordinates at building precision, permanently, to anyone who downloads it. The customer did not know it was in there. Neither did the technician, or marketing.
Nothing about this is exotic. It is the default behaviour of a phone camera combined with the default behaviour of a CMS that stores what it is given. And it scales badly: a gallery of forty completed jobs is a downloadable map of forty customers' homes.
The same mechanism produces several other quiet exposures:
- Home-office businesses. A geo-tagged product photo shot on the kitchen table publishes the owner's residential address, which is often the address they have deliberately kept off the site.
- Staff photography. A set of images of the same employee across months, each with coordinates and timestamps, is a movement record. That is materially different from one photograph, and nobody consented to it.
- Property and vehicle work. Photographs of a client's premises or vehicle at their address, which is precisely the kind of detail a client would prefer not to be public.
Deciding per image
The two site-wide policies are both wrong. Strip everything and you throw away legitimately useful metadata on your own premises. Keep everything and you publish customers' addresses.
The question is whose location the file records:
Keep the metadata when it records your own business location. Your storefront, your workshop, your yard, your van outside your own unit. Here the coordinates make a true claim about a place you have already published, and that claim is genuinely useful. How GPS EXIF actually works for local visibility covers the honest scope of the benefit, which is real but modest and easily overstated.
Strip the GPS when the file records anyone else's location. Customer sites, employee homes, third-party premises. There is no version of this where the coordinates are doing useful work for you, and the downside is real.
Strip timestamps as well where the pattern matters. One timestamp is nothing. Forty timestamps across one person's photographs is a schedule.
Keep the author-written fields either way. Description, copyright, artist. You wrote them, they contain exactly what you intended, and they are the part of metadata with any genuine value for search and for provenance.
Making it routine rather than remembered
A policy that depends on someone remembering will fail on the day it matters, because the failure is silent and nobody is checking.
The reliable placement is at ingestion — the point where a file enters your systems. A processing step that strips the GPS block from anything uploaded from a phone, while leaving author fields intact, covers the overwhelming majority of the exposure without anyone thinking about it. Where the business genuinely wants coordinates on its own premises photography, those get written deliberately afterwards, which is the correct order anyway: strip what a device recorded incidentally, add what you meant to say.
Two practical notes.
Some hosting and CDN pipelines strip metadata during processing as a byte-saving measure, which accidentally solves this and simultaneously removes the metadata you wanted to keep. Whether yours does is worth establishing rather than assuming, because it determines whether you are relying on a control or merely benefiting from a side effect — and it varies by provider, as what a CDN does to your files sets out. Verify against the file as actually served from the public URL, not the original on a desktop.
Large platforms mostly strip on upload too, but inconsistently and without documentation, and it changes. It also does nothing for images served from your own domain, which is where most of your exposure is.
Verification
The check is short and worth running once against real published files.
- Download three or four images from your own live site, chosen from the riskiest categories: completed work, team photos, anything shot on location.
- Run ExifTool against them and read the full output.
- Look specifically for a GPS block. If present, put the coordinates into a map.
- If the pin lands on somewhere that is not your premises, you have found the problem and it is very unlikely to be limited to those files.
- Fix at the ingestion step, then remediate the existing library.
Remediation of an existing library is a bulk metadata strip, which is fast and safe on the GPS block specifically. It does not require renaming or re-uploading anything, so it carries none of the risk that comes with changing published image URLs.
If you find you have already published it
Discovering coordinates on a hundred published customer photographs is uncomfortable and entirely recoverable. The sequence matters more than the speed.
Strip and republish first. Remove the GPS block from the affected files and replace them at the same URLs. Same URL matters here, because it means every page keeps working and there is nothing to redirect. This is the only step that stops the exposure growing.
Then deal with what is cached. Copies may persist in search caches, in a CDN, and in anything that has already downloaded them. Purging your own CDN is immediate and worth doing straight away. Search-side caches expire on their own schedule and cannot be meaningfully hurried, which is a reason to act promptly rather than a reason to panic.
Then decide about notification. Whether affected individuals need to be told is a question about your jurisdiction, the sensitivity of what was exposed and how long it was public, and it is a question for whoever advises you on data protection rather than for a marketing decision. What is worth recording either way is the date you found it, the number of files, and what you did — because that record is the difference between a handled incident and an unhandled one.
Then fix the ingestion step, so the same batch cannot arrive again next quarter. A remediation without that is a task you will repeat.
Proportion is worth keeping. This is a category of mistake that essentially every business making before-and-after content has made at some point, it is silent, and the fix is a bulk metadata operation rather than a rebuild.
Telling the people who take the photographs
The technicians and staff generating these files are not going to read a data-protection policy, and they do not need to. They need one sentence and one setting.
The sentence: photographs taken at a customer's address record that address inside the file, so job photos go through the shared upload rather than straight into the website.
The setting: on both major mobile platforms, location tagging for the camera can be switched off in the operating system's privacy settings, per app. Turning it off on a work phone used for job documentation solves the problem at source, costs nothing, and removes the dependence on anyone remembering anything later.
Where the same phone is also used for photographing your own premises, leave it on and strip selectively at ingestion instead. Either arrangement works. What does not work is having no arrangement and assuming the CMS handles it.
Where this meets the other metadata conversations
Two adjacent subjects use the same fields for different purposes, and it helps to keep them distinct.
Provenance and AI disclosure. Content credentials and generation markers are metadata you deliberately add so that downstream systems can tell where an image came from. That is an additive practice with a transparency motive, and a blanket strip-everything policy quietly deletes it. What actually reaches the user when you label an AI-generated image explains why the field survives some pipelines and not others.
Rights and licensing. Copyright and creator fields are the cheapest form of embedded attribution and there is no privacy reason to remove them. They travel with the file, which is the entire point, and they matter more as imagery gets syndicated and scraped. The broader position on what you may and may not do with generated images commercially sits alongside this.
Photos you hand to Google directly. Images uploaded to a business profile are a special case, since the location claim there is made by the profile itself rather than by the file. The metadata is doing much less work than people assume, and what actually moves the needle on business profile photos is mostly about subject and freshness.
The short policy
Keep author fields always. Keep GPS on your own premises. Strip GPS on anyone else's. Strip timestamps where a pattern could be assembled. Enforce it at ingestion rather than by memory, and verify against files as served rather than as stored.
That is five lines, it fits in an onboarding document, and it prevents the one image-metadata mistake that has consequences beyond search.
Frequently asked questions
Should you remove EXIF data from images before publishing them?+
It depends entirely on whose location the file records. Metadata describing your own premises is useful and worth keeping, while metadata recording a customer's home, an employee's movements or an unrelated third party's property should be removed before publication. The workable policy is per-image and based on the subject rather than a site-wide setting in either direction.
Do phone photos really contain GPS coordinates?+
By default yes, on both major mobile platforms, at a precision that typically resolves to a specific building. Photographers frequently do not realise this because the coordinates are invisible in every normal viewing context and only appear when the file is inspected directly. A photo taken inside a customer's home therefore carries that address in the file unless something removes it.
Does removing EXIF data hurt SEO?+
No. Metadata is a weak signal at best and there is no documented ranking penalty for its absence, so stripping it costs nothing measurable in search terms. The genuine loss is in the specific cases where the metadata was making a true and useful claim, such as GPS coordinates on a photograph of your own business location.
Which EXIF fields are a privacy risk?+
The GPS block is the significant one, since it can identify a building. Timestamps are a secondary risk because they establish when someone was somewhere, and device serial numbers plus owner or artist fields can link a set of images to one individual. Description and copyright fields are author-written and carry only what you deliberately put in them.
Do platforms strip metadata automatically when you upload?+
Most large social and ecommerce platforms do, but the behaviour is inconsistent, undocumented and subject to change without notice. It also does not help with images served directly from your own site or CDN, which is where the exposure usually sits. Treat automatic stripping as a bonus you cannot rely on rather than as your control.
Is publishing a customer's location in image metadata a GDPR issue?+
It can be, because location data tied to an identifiable individual is personal data under the regulation, and publishing a customer's home coordinates without a lawful basis or their awareness is difficult to justify. Similar reasoning applies under several US state privacy laws. This is a question for your own legal advisers, but the safe operational default is to strip customer-location metadata as a matter of routine.
How do you check what metadata an image contains?+
ExifTool is the standard tool and reads every field including the GPS block, and most operating systems also expose a partial view through file properties or an info panel. Check the file as actually served from your public URL rather than the original on your desktop, because processing pipelines may have added or removed fields on the way.
Should staff photos have location metadata removed?+
Generally yes, unless the location is your own published premises. A set of photographs of the same employee carrying coordinates and timestamps forms a movement record, which is a meaningfully different thing from a single image, and it is rarely something anyone consented to. Keep the business address where relevant and strip everything else.
Let SEOpix handle the metadata
Filenames, alt text, EXIF fields and GPS coordinates written automatically as each image is generated. Start with 10 free images a month — no credit card required.
