What metadata the images on your own website still carry

Three things make a site you operate different from a feed you post to. First, the safety net is gone: there is no platform re-encoder to accidentally save you. Second, the files are already public, at URLs that persist and are often trivially guessable. Third, it is not one file — it is an archive that accumulated over years, uploaded by past contributors, imported in bulk, and migrated between systems, all under a policy that probably never existed.

Why your own publishing surface behaves differently

Nothing strips anything unless you made it. Whether metadata survives your stack depends on the image library on the server, its configuration, its version, and any plugin or build step in front of it. Some pipelines discard most of the header as an incidental side effect of re-encoding a resized copy. Others carry parts of it across on purpose, because photographers want their credit and copyright fields to survive. Some do different things to different formats. You cannot read this off a settings page with confidence, and you should not infer it from what a plugin's description claims — it is a property of the bytes your server actually returns, which means it has to be measured rather than assumed.

The original upload is usually still reachable. Publishing systems commonly generate a family of sizes from a single upload and keep the untouched original next to them. Even when the resized derivatives come out clean, the original often does not, and it is rarely hidden: responsive srcset attributes, lightbox links, gallery "view full size" behaviour, feed enclosures, and social preview tags all tend to point at the largest available file. An audit that only inspects the picture rendered in the layout can pass while the more revealing file sits one predictable URL away.

Your URLs are enumerable. Upload directories on most platforms follow a convention, frequently including a date path. Sitemaps, feeds, and archive pages list them for you. Nobody needs to guess. The practical consequence is that "no one will find that old post" is not a defence — a crawler already did.

Your image is republished by things you do not run. RSS and Atom feeds, link-preview scrapers, syndication partners, newsletter services, and web archives all take copies, and the copy they take is often the original rather than the version on your page. Each of those copies has its own lifetime and its own cache, and none of them is refreshed by you editing a post.

The pipeline is only as careful as its least careful contributor. If several people can publish, the question stops being "did I clean this file" and becomes "what happens by default when someone who has never thought about EXIF drags a photo in at 11pm." Individual diligence does not scale; a default does.

A practical audit of a site you already run

1. Inventory where images enter. Manual uploads, bulk imports, a static-site build directory, a headless CMS, contributor submissions, an e-commerce product feed. Each entry point is its own pipeline and can behave differently.
2. Test the served bytes, not your local copy. Download an image from its public URL and inspect that file. The copy on your laptop is the input; what matters is the output your server actually produces after whatever processing happens in between.
3. Test the biggest file, not the displayed one. Open the page source or dev tools, collect every candidate URL for the same image — the rendered size, the srcset entries, the lightbox target, the Open Graph image — and check the largest.
4. Sample deliberately across eras. Check a recent upload, something from before your last platform or theme change, and something from a bulk import. Behaviour changes with software versions, so one clean result proves very little about a ten-year archive.
5. Sort by risk, not by volume. Photos taken at home, at a client's premises, or at a contributor's address matter far more than stock illustrations and screenshots of a dashboard. Location and capture-time fields are the ones worth prioritising.
6. Fix the default before the backlog. Whatever you do to old files, the archive grows again next week unless the entry point changed. Decide what the pipeline should do, then implement it once.
7. Then work the backlog, worst first. For a handful of files, cleaning by hand is fine. For thousands, a server-side batch tool is the honest answer — and either way you want a record of what has been done.

Where the browser tool fits in that loop is narrow but real. MetadataWipe handles one JPEG or PNG at a time: you choose a file from your device, it runs a fast heuristic check for metadata markers, it builds a cleaned copy by re-drawing the image, and you download that copy with -metadatawipe appended to the name. Everything happens locally, with no account and no server transfer. That makes it well suited to checking what a sampled file from your site contains, to cleaning a specific image before you publish it, and to fixing the small number of files an audit flags — and poorly suited to sweeping an archive of ten thousand product photos, which wants automation on the server instead. Treat its built-in check as a quick look at the front of the file, not a forensic audit.

Replacing an image that is already live

Remediation on a site you control has one advantage and one trap. The advantage: you can genuinely replace the file, which most people sharing to a platform cannot. The trap is assuming that replacement is retraction. Overwriting an image at the same path updates what your origin serves, but caches at the CDN edge, in browsers, in feed readers, and in archives keep their own copies until they expire or until you purge them. Search engines hold their own stored thumbnails and refresh on their own schedule — the mechanics of that, and why cleaning a file locally does nothing to a search result, are covered in does removing EXIF data remove a photo from search engines. Publishing the cleaned file at a brand-new URL and deleting the old one is sometimes cleaner, but it breaks inbound links and leaves the old path returning a 404 rather than a clean image, which has its own costs. Decide which you want before you start renaming things.

Common mistakes and misconceptions

"We clean everything before it goes up." Someone did, once, for the images they personally handled. Bulk imports, migrated archives, and other contributors are where the exceptions live, and they are invisible from the dashboard.

"The CMS strips it." Sometimes true, and version-dependent. It also frequently applies only to the generated sizes and not to the preserved original. Verify against the file the server hands out, not the documentation.

"Platforms strip metadata, so this is a solved problem." That reasoning belongs to a different situation. Social networks commonly re-encode uploads and drop much of the payload, unevenly and inconsistently — see which social platforms strip photo metadata automatically — but your own web server is not doing anyone that favour by default. Self-hosting means you inherited the job.

"Nothing shows in the page, so nothing is in the file." Metadata is not rendered. A page can look entirely innocuous while the JPEG behind it carries coordinates, a camera serial, editing software names, and an author field filled in by a tool nobody remembers installing.

"It's an old post, it doesn't matter." Old posts are exactly where the untreated files are, and age does not make a home address less current if the contributor still lives there.

"Stripping metadata makes the site anonymous." It removes one class of leakage. Visible content in the photos, filenames, directory paths, post dates, and everything else your site publishes about you are all still there — as with any single control, it is part of the answer rather than the whole of it.

Related guides

See also:

• Which social platforms strip photo metadata automatically?
• Does removing EXIF data remove a photo from search engines?