In what order should you crop, edit and strip metadata from a photo?

Almost every guide to photo metadata — including most of the ones on this site — treats stripping as a single, isolated act: here is a file, here is the thing you do to it. Real files are rarely handled that way. Before a photo gets shared it typically gets cropped, straightened, resized, maybe blurred over a face or a house number, and exported at least once. Stripping is one step in a sequence, and the position you give it in that sequence changes the file you end up with.

Ready for the last step? MetadataWipe rebuilds a JPEG or PNG in your browser — no account, and the file stays on this device.

Open MetadataWipe tool

This is a different question from "does cropping remove GPS" or "which platforms strip metadata automatically". Those are questions about what a single operation does. This one is about scheduling: given that you are going to perform several operations anyway, which one goes last, and what does it cost you to get that wrong. The answer is short — strip last — but the reasoning behind it is what tells you when to break the rule.

Two reasons the order has consequences

The first reason is that stripping is not durable. It removes what is in the file at the instant you run it. It does not confer any property on the file that makes it resistant to acquiring metadata later. Every application that opens an image and writes it back out produces a header of its own choosing, and the usual contents are a processing-software or creator field, a date, frequently a freshly generated embedded preview, and in some workflows fields pulled forward from the application's own catalogue rather than from the file you opened. What a given editor writes is a property of that editor and its settings, which is the subject of what metadata a photo editing app adds or removes. The practical consequence for sequencing is simple: a strip performed before an edit is undone, in part, by that edit.

The second reason pulls the other way, which is why this is a real trade-off rather than a rule you can apply blindly. JPEG compression is lossy, and each time a JPEG is decoded and encoded again it is a new generation built from the previous one's approximation rather than from the original. Pixel-level edits necessarily cost a generation. So does any metadata tool that works by rebuilding the image rather than by editing the header in place. If you interleave strips and edits — strip, crop, strip again, resize, strip once more — you are not only failing to end up cleaner, you are paying a compression penalty for each pass. The fewer saves between the original and the file you send, the better, and that argues for consolidating rather than sprinkling.

Put together, the two reasons point at the same shape: do the pixel work in as few passes as you can, then strip, then stop touching the file.

The default sequence

Leave the original alone. Work on a copy. The original is your fallback if an edit goes wrong, and it is also the only thing that still holds the metadata — which you may want for your own records even though you are not publishing it.
Do all the pixel work in one session, and export once. Crop, straighten, resize to the dimensions you actually need, adjust colour, blur or paint over anything identifying. Doing these in a single editing pass rather than as a chain of separate exports is the single biggest thing you can do for image quality.
Strip metadata, on the exact file you are about to send. Not on a sibling, not on the version before your last tweak. The bytes that are going.
Verify on that same file. The one you just produced, not the one you produced before it.
Rename if the filename says something. A strip does not touch the name, and names routinely carry a date, a location, a client, or a camera's own sequence pattern.

Why "strip first" feels right, and usually is not

The instinct to strip first is an instinct about urgency rather than about files. Privacy feels like the important step, important steps feel like they should happen immediately, and there is a quiet sense that getting the sensitive data out early reduces the window in which something could go wrong. None of that is unreasonable as a reflex. It just does not match how the file behaves, because the editing you do afterwards writes a new header onto a file you had already cleaned, and you finish with a photo that has metadata in it and a memory of having removed the metadata.

Cropping deserves a specific mention here because it is the operation people most often expect to do double duty. Changing which pixels are in the frame does not reach into the header — the coordinates and the timestamp sit in a structured block that the crop does not address, which is covered directly in does cropping a photo remove GPS metadata too. There is a second, subtler reason to crop before you strip rather than after: many files carry an embedded preview image, and whether an editor regenerates that preview after a crop, or copies the old one across unchanged, varies by application. A strip that happens last removes the preview whatever the editor decided to do with it. A strip that happens first leaves you trusting the editor.

The exceptions worth knowing

Somebody else is doing the editing. If a file is going to a retoucher, a designer, a print shop or a web-based editor, strip before it leaves your hands — that is the whole point — and then strip again on whatever comes back. Two passes, deliberately, because the returned file was written by software you did not configure.

The file is a PNG. PNG compression is lossless, so a re-encode reproduces the same pixels and the generation-loss half of the argument largely disappears. The re-accrual half still applies, so stripping last is still the better habit, but reordering is no longer expensive.

Your editing step is the risk. If the thing doing the editing is a cloud service or an app whose data handling you have reason to doubt, strip first regardless of the quality cost. A lossy generation is a known, bounded price; a location history going somewhere you did not intend is not.

You are not actually editing. If the only thing happening to the photo is that you are sending it, there is no sequence to get wrong. Strip and send.

Where this site's tool sits in the sequence

MetadataWipe takes one JPEG or PNG at a time, decodes it in your browser, draws the decoded image onto a canvas at its original pixel dimensions, and exports a new file from that canvas. Three things about that mechanism bear on ordering.

It belongs at the end, because the file it produces is generated rather than copied: no part of the original container carries across, so there is nothing to inherit regardless of which standard the original metadata was written in. It costs a generation for JPEG, because the export is a fresh encode at a fixed quality setting written into the code — a reason to run it once, after the editing, rather than between edits. And it does not crop, resize or compress to a target, so it is never a substitute for the editing phase; it does not change dimensions at all.

One ordering detail is easy to miss. The browser API the tool uses applies EXIF orientation when it decodes, per the specification's default behaviour, which means a photo tagged as rotated comes out with the rotation baked into the pixels and no longer needing a tag to display correctly. The tool's own source carries a note to re-check this on older iOS Safari versions, so if you are on an old browser and orientation matters, look at the downloaded file before you send it. The original is left untouched on disk and the download arrives with -metadatawipe in its name, which matters at the final step: the ordering failure that actually bites people is attaching the original by mistake.

Common mistakes and misconceptions

"I stripped it, so it is clean now." It was clean at that moment. Anything that has opened and saved it since has written its own header.

"I cropped the corner out, so the location is gone." Cropping is an operation on pixels. Coordinates are not pixels.

"I will strip it now while I am thinking about it and edit it tomorrow." This is the single most common way the sequence goes wrong, and it feels like diligence.

"Screenshotting it is my strip step." A screenshot is a resize and a re-encode that happens to discard the original header — so it is an editing operation with a side effect, not a cleaning step, and the resulting file carries whatever your device writes into screenshots.

"More passes is safer." With a rebuild-style cleaner on a JPEG, each extra pass is another generation for no additional cleaning. One pass at the end removes exactly as much as five.

"I compressed it first to save the platform the trouble." Many platforms re-encode anyway, so your pass usually sits underneath theirs rather than replacing it.

"I checked the file and it was clean." Check the file you are sending, after the last thing you did to it. A verification performed one edit ago has verified a file that no longer exists.

Related guides

Frequently asked questions

Should I strip metadata before or after cropping a photo?

After, in almost every case. Stripping is not a property the file acquires — it only removes what is present at the moment you run it. If you strip and then open the result in an editor to crop it, that editor writes the saved file itself, and what it puts in the header is up to the software: typically a creator or processing-software field, often a fresh embedded preview, sometimes fields carried forward from its own catalogue. You have spent an editing generation and finished with a file that has metadata in it again. Cropping last also leaves you relying on the editor to handle the original embedded thumbnail correctly, whereas a strip performed last clears any preview regardless of what the editor did with it.

Does running a metadata cleaner count as a lossy save?

It depends entirely on how the cleaner works, and it is worth knowing which kind you have. A cleaner that edits the file's header in place and leaves the compressed image data untouched costs you nothing in pixels. A cleaner that works by decoding the image and re-encoding it — which is what this site's tool does — produces a genuinely new encode, so for a JPEG that is one more lossy generation. Neither approach is wrong, but the second one is a reason to run it once, at the end, rather than repeatedly in the middle of an editing session. For a PNG the distinction barely matters in practice, because PNG compression is lossless and a re-encode reproduces the same pixels.

What if someone else is doing the editing?

Then you need two strips, not one, and the first of them comes first. Strip before the file leaves your hands, because the privacy question is about who can read the coordinates and the device details, and a retoucher, a designer or an online editing service is somebody who can. Then strip again on whatever comes back, because the software that produced it wrote a fresh header you did not choose and cannot inspect from the outside. Treating the returned file as clean because you cleaned the file you sent is the specific mistake this sequence exists to prevent.

Should I resize or compress a photo before uploading it somewhere?

Resize once if you genuinely need smaller dimensions, and be sceptical about compressing on top of that. You are usually not the last step in the chain: many platforms re-encode what they receive to their own settings, so a quality pass you add beforehand is an extra lossy generation stacked underneath theirs rather than a substitute for it. Where the ordering advice is unambiguous is relative to the strip: do the resize as part of your editing phase and strip afterwards, so that whatever the resizing tool wrote into the header is removed rather than shipped.

Finished editing? Make the strip your last step — JPEG or PNG, rebuilt in your browser.

Try MetadataWipe free