Does stripping metadata change a photo's file hash?

Two identities, and only one of them is the file

It is worth separating the vocabulary before anything else, because "hash" gets used for both of these and they behave nothing alike.

• A cryptographic hash — SHA-256, SHA-1, MD5 — is a fixed-length digest computed over the file's bytes from beginning to end. Its defining property, as Wikipedia's description of cryptographic hash functions states, is that even a small change in the input results in a very different hash, which is what makes it an efficient and consistent way to check whether two copies of data match. It answers exactly one question: are these two files byte-for-byte identical? It knows nothing about pictures.
• A perceptual hash — pHash, dHash, PhotoDNA, and the various in-house fingerprints platforms run — is computed from the decoded image. Wikipedia characterises perceptual hashing as a locality-sensitive fingerprint of multimedia whose values remain analogous when the features of the content are similar, explicitly in contrast to the avalanche behaviour of cryptographic hashing, and notes its wide use in finding online copyright infringement and in digital forensics. It answers a fuzzier and much more useful question: is this the same picture, give or take?

Metadata sits inside the first and outside the second. That single sentence predicts everything below.

The file hash: it changes, every time, with no exceptions

EXIF blocks, XMP packets, IPTC records, MakerNotes, embedded thumbnails and PNG text chunks are not annotations hovering beside the file. They are bytes within it, in the same byte stream the hash function walks. Remove them and the input to the hash is different, so the output is different — and because of the avalanche property, it is not slightly different. You get a value with no recognisable relationship to the original. One deleted GPS tag produces as unrecognisable a digest as replacing the entire photo would.

There is no clever workaround. You cannot strip metadata and preserve a checksum, you cannot strip metadata and keep a file-level digital signature valid, and no tool restores the original bytes afterwards from the cleaned copy. This is the single most consequential thing on this page, so it is worth stating as a rule: if a file's hash matters to anyone, do not strip that file — strip a duplicate.

Where that bites in practice:

• Evidence and chain of custody. Hashing a photo on acquisition and re-hashing it later is how anyone demonstrates nobody edited it in between. Stripping the preserved copy destroys that demonstration permanently and, worse, looks like tampering. The preservation side of this is covered in how courts use photo metadata as evidence, and the short version is: work from a duplicate, always.
• Published checksums and signed manifests. If you distributed a photo with a SHA-256 alongside it, or signed a bundle of images, cleaning the metadata on the shipped file invalidates the published value. Re-publish the new digest or re-sign; there is no third option.
• Deduplication and sync. Systems that recognise an already-stored file by its digest will not recognise the cleaned copy, so expect a second stored object rather than a replacement. That is often precisely what you want — a fresh clean file instead of a silent merge with the old one — but it does mean the original is still sitting there until you delete it deliberately.
• Known-file filtering. Hash-based blocklists and allowlists match exact files. A re-encoded copy is a new file to them.

And a nuance on algorithm choice, since people reach for whatever their shell has: MD5 and SHA-1 are perfectly adequate for spotting an accidental difference between two files, but both have known collision weaknesses, so for anything where someone might deliberately substitute a file — evidence, distribution, signing — use SHA-256.

The perceptual fingerprint: it survives, by design

Now the other direction, which is where the hopeful misconception lives. People strip metadata expecting a photo to become unrecognisable to automated matching. It does not, and the reason is structural rather than incidental: content-matching systems were built specifically because file hashes were useless for this job. A file hash misses every resized, re-saved, re-compressed and screenshotted copy — which is nearly every copy in circulation. So matching systems skip the header entirely and fingerprint the picture.

PhotoDNA is the best-documented example of how literal that is. It was developed by Microsoft Research with Hany Farid of Dartmouth College from 2009, and its method is described as converting images into a black-and-white format, dividing them into squares, and quantifying the shading of those squares — a design that, as its description notes, sought to be resistant to alterations in the image including resizing and minor colour alterations, and which neither uses facial recognition nor identifies people or objects. Microsoft donated the technology to Project VIC, managed with the International Centre for Missing & Exploited Children, where it is used in digital forensics to store fingerprints that identify an individual photo, and since 2015 comparable methods have been applied to individual frames of video.

Read that method description once more and notice what is absent: any reference to the file's header. There is no step at which EXIF, XMP or a text chunk enters the calculation. An emptied header is not a small change to a perceptual hash — it is no change to a perceptual hash. Reverse image search behaves on the same principle; researchers have described Google's image search as perceptual-hash based, and the practical consequence is the one covered in does removing EXIF data remove a photo from search engines: cleaning a header does not de-index a picture.

What this site's tool actually does to each layer

Stated precisely from the code, because the format split changes the answer. MetadataWipe accepts image/jpeg and image/png only, one file at a time. It decodes the image in the page, draws it to a canvas at the source's original pixel dimensions, and exports a brand-new file from that canvas — which is why every metadata structure that lived inside the source is absent from the result, whether or not the in-page scanner could name it.

• PNG input. The canvas export is lossless PNG. Decoded pixels in the clean copy are identical to the original's; the file bytes differ, because a different encoder wrote a different chunk layout with no text chunks, no eXIf and no tIME. File hash: completely different. Perceptual fingerprint: unchanged, since the picture is bit-for-bit the same picture.
• JPEG input. The clean copy is re-encoded at quality 0.92, so the compressed data is newly generated and the decoded pixels shift very slightly from a second round of lossy compression. File hash: completely different. Perceptual fingerprint: effectively unchanged, because a single re-encode at that quality is comfortably inside the tolerance those algorithms are built around.
• Either way, the exported file is named with a -metadatawipe suffix, so you will not overwrite the original by accident — which is exactly the behaviour you want if the original's hash still matters to someone.

One caveat on the scanner, since it is easy to over-read. The in-page metadata check is a deliberately lightweight heuristic: it reads the start of the file and looks for a JPEG EXIF marker, a loose GPS string, and the PNG chunk types that commonly carry text. "No obvious metadata detected" means those markers were not found near the top of the file. It is not a hash comparison and not a forensic parse, and it is not the right instrument for answering questions about file identity.

Checking a hash yourself, in one command

Everything above is verifiable on your own machine in under a minute, and doing it once is worth more than trusting this page. Hash your original, clean a copy, hash the copy, compare.

• macOS: shasum -a 256 photo.jpg
• Linux: sha256sum photo.jpg
• Windows, Command Prompt: certutil -hashfile photo.jpg SHA256
• Windows, PowerShell: Get-FileHash photo.jpg -Algorithm SHA256

A short workflow that keeps both identities straight:

1. Decide which identity you need before you strip. If anyone downstream will verify a digest, the original is untouchable and you work from a duplicate. If nobody will, the question is moot and you can clean freely.
2. Record the original's digest first — the value, the algorithm and the date. A digest with no recorded algorithm is close to useless later.
3. Duplicate, then clean the duplicate. Never the file you are preserving.
4. Hash the cleaned copy too, so the sanitised version has its own verifiable identity rather than being an undocumented derivative.
5. Note the relationship in writing. "Digest B is a metadata-stripped, re-encoded derivative of digest A, produced on this date" is a sentence that answers a lot of later questions.
6. Do not expect the clean copy to stop matching anywhere. If your actual goal is that a picture stops being findable or linkable, the problem is the pixels and the places it has already been, not the header.

Common mistakes and misconceptions

"The hash changed, so something altered my photo." A changed digest tells you the bytes differ. It says nothing about whether the picture differs. Strip the metadata from a PNG and you get a wildly different hash over a pixel-identical image. Byte identity and visual identity are separate claims and a hash only ever speaks to the first.

"Stripping metadata will stop the platform recognising my photo." It will not. You are changing the layer that matching systems ignore and leaving untouched the layer they measure. This is the most common version of the misconception and the most reliably disappointing.

"I'll strip first and hash afterwards." Then you have a digest for the redacted file and nothing for the original, which is the wrong way round if the point was to show the original was never edited. Hash first. The order is the whole technique.

"A tool can remove metadata without changing the file." Not in any meaningful sense. Some editors rewrite tags in place rather than re-encoding the image, which preserves the pixel data exactly — but it still changes bytes, so it still changes the hash. In-place is about image quality, never about file identity.

"The hash is the same, so the strip failed." That reading is correct, unusually. An identical SHA-256 means the file is byte-for-byte what it was, so nothing was removed and you are probably hashing the original by mistake rather than the downloaded clean copy. Check the filename.

"MD5 is good enough." For catching accidental differences, yes. For demonstrating that nobody swapped a file, no — MD5 and SHA-1 both have practical collision attacks. Use SHA-256 whenever the digest is doing anything adversarial.

Related guides

See also:

• How courts use photo metadata as evidence
• Does removing EXIF data remove a photo from search engines?