When the part you cropped out is still in the file

This is worth separating from the ordinary advice because the stakes are inverted. A leaked GPS tag tells someone where a photo was taken. A recoverable crop hands them the thing you specifically decided they should not see, which is usually far more sensitive than anything in a header, and it does it with no forensic skill required — often just a different application opening the same file.

Two meanings of "removed"

Every edit lands in one of two categories, and nothing about the on-screen result tells you which.

Destructive. The tool decodes the image, throws away the pixels outside your crop, and writes a new file from what remains. The removed region stops existing. This is what most people picture when they crop, and it is what a plain image editor exporting a new JPEG or PNG normally does.

Stored as an instruction. The tool keeps the original picture and records your edit next to it — a crop rectangle, an adjustment list, an overlay object, a visible frame smaller than the content. The display honours the instruction. The file still holds the whole thing. Document formats work this way because they are meant to be editable, photo libraries work this way so you can revert, and layered editors work this way by definition.

The second category is not a bug. It is the point of those formats. The bug is assuming you were in the first category.

Office files keep cropped areas by design

This is the most widespread version of the problem and the easiest to verify, because Microsoft says so in its own documentation. The support article on cropping a picture in Office carries an explicit warning that cropped parts of the picture are not removed from the file and can potentially be seen by others, and its section on deleting those areas states that by default, after you crop a picture, the cropped areas remain part of the file, hidden from view — adding that removing them also helps prevent other people from viewing the parts of the picture you have taken out.

So a screenshot pasted into a Word report, cropped down to the one chart you meant to show, can travel as a document that still contains the full capture: the tabs, the file path, the client name in the window title. The person who receives it does not need a hex editor. They need to drag the crop handles back out, or unzip the file and look at the stored image.

The fix lives somewhere other than the crop control, which is why it gets missed. Select the picture, go to Picture Format, choose Compress Pictures, and confirm the Delete cropped areas of pictures checkbox is ticked; there is an Apply only to this picture option if you want to limit it. Microsoft notes the deletion can be undone until the file is saved — the flip side being that after saving, it is permanent, which is exactly what you want. Two habits avoid the whole dance: crop in an image editor and insert only the piece you need, and remember that dragging a picture smaller on a slide changes how big it looks, not how much of it is stored.

The screenshot editors that let people un-crop old captures

In March 2023 this stopped being a filing nuance and became a named vulnerability. aCropalypse — CVE-2023-21036 — was a flaw in Markup, the screenshot editor on Google Pixel phones, published findings credited to researchers Simon Aarons and David Buchanan, with the underlying behaviour having been filed to Google's issue tracker by Lucy Phipps in August 2022.

The mechanism is worth understanding because it explains a whole class of failures. When you saved an edited screenshot, the editor wrote the new, smaller image over the file holding the old one — but opened that file in a mode that did not truncate it. The new image ended where it ended; the remaining bytes of the longer original were still there, after it. Image viewers stop reading at the end-of-image marker, so the file looked perfectly normal and showed your cropped version. A tool that read past that point could reconstruct much of what you had cut off or painted over. Reporting at the time traced the behaviour to a change in Android 10, with the Pixel fix shipping in a March 2023 security patch. Days later the same pattern was found in the Windows 11 Snipping Tool and the Windows 10 Snip and Sketch app, assigned CVE-2023-28303 and recorded as a Windows Snipping Tool information disclosure vulnerability.

Three durable lessons, independent of those particular versions. First, an unexpectedly large file is a signal — a mostly-black cropped screenshot that weighs several megabytes is telling you something. Second, a patch fixes future saves and does nothing for the file you already sent; whether a shared copy survived depended on whether the receiving service re-encoded uploads, and some did while some did not. Third, "I used the built-in tool" is not a security property. The built-in tool was the vulnerable one.

Covering is weaker than cropping

When the thing you want hidden sits in the middle of the frame, people reach for a shape, a highlighter, a blur or a marker stroke. All of these are weaker than a crop, in two separate ways.

Mechanically, a rectangle drawn in a document, a PDF annotation or an editor layer is an object placed above the content. Unless the application flattens it into the image or performs a real redaction that removes the underlying content, the thing beneath is still in the file and the next application that opens it may let the covering object be moved, hidden or deleted. If you must cover rather than crop, use an opaque solid fill and then flatten or export so the fill becomes image data, and verify in the exported file rather than in the editor.

Informationally, blur and pixelation are poor choices for short predictable strings. A name, an account number, a licence plate or a six-digit code has a small, well-structured space of possibilities, and a degraded rendering of a known format leaks more than a solid block does. Reserve blur for faces and scenery; use a hard fill, or a crop, for text.

The same caution applies to the small preview some files carry. An embedded thumbnail generated before your edit can still show the earlier frame, so a crop can be undone by a file's own preview rather than by anything clever.

A workflow that leaves nothing behind

1. Decide first whether this removal has to be irreversible. Hiding a detail in a draft you will keep editing is a different job from preparing a file for a stranger. Only the second one needs to be destructive.
2. Work on a duplicate. Flattening and destructive crops cannot be undone once saved, so keep the untouched original somewhere you will not confuse with the outgoing copy.
3. Capture less rather than cropping more. For screenshots, select the region you want at capture time. There is nothing to recover from a capture that never included the rest of the screen.
4. Do the pixel work in an image editor and export a new file. Use Save As or Export to a fresh JPEG or PNG rather than saving in a layered or project format. The export is the step that makes the edit real.
5. If the image lives inside a document, clean it there too. In Office that means Compress Pictures with the delete-cropped-areas option; in other formats, prefer inserting a pre-cropped image over cropping in place.
6. Check the size as a sanity test. A heavily cropped file that is barely smaller than the original, or far larger than its dimensions suggest, is worth a second look.
7. Reopen the exported file and inspect it as the recipient will. Full size, all four edges, every corner. Try dragging the crop handles in a different application. Look at the thumbnail the operating system shows.
8. Strip the tag layer last. Running a metadata strip before you finish editing just gives the editor a chance to write a fresh header on the way out.
9. Rename the file. Screenshot_2026-10-05_portal-admin.png survives every crop, flatten and strip you will ever run.

Step 8 is the sequencing question in its own right: an edit after a strip can write a fresh header, while an edit before it leaves nothing for the strip to miss. The narrower question of whether a crop touches location tags at all is answered in does cropping a photo remove GPS metadata too.

Common mistakes and misconceptions

"The preview shows the crop, so the data is gone." The preview shows what the application decided to render. In every case described above the rendering was correct and the file still held the original.

"My phone is updated, so my old screenshots are fine." A patch changes how files are written from then on. It cannot reach into a file you saved last year or a message you sent last week.

"A black box is a redaction." Only if the application removed the content underneath. Drawn shapes, highlights and annotation markup are objects on top, and the next tool to open the file may simply move them.

"Resizing the picture in the document shrinks the file." Display size and stored data are unrelated. A full-resolution photo scaled to thumbnail size on a slide is still a full-resolution photo inside the file.

"Saving again flattens everything." Saving in the same editable format normally preserves editability — that is its job. Exporting to a flat image format is what flattens.

"Stripping metadata deals with it." It deals with the tag layer, and with trailing data that falls outside the image stream. It cannot open a document to find a cropped picture inside, and it cannot remove anything that is still visible in the frame.

"Screenshotting my own cropped image is a safe shortcut." It is actually a reasonable trick — a fresh capture of the rendered result contains only what was displayed — but it inherits whatever the capture tool itself does on save, and it reduces quality. Treat it as a fallback, then verify the result like any other file. What a screenshot does and does not carry is set out in what metadata does a screenshot contain.

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

Stated precisely, 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 onto a canvas at its 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 — names it with -metadatawipe appended, and leaves your original alone. All of that happens inside the page on your own device; nothing is sent anywhere.

Because the export is written from the decoded pixels rather than copied from the input bytes, two things do not survive: the tag layer, and anything sitting beyond the end of the image stream — which is the shape of the leftover tail the 2023 screenshot flaw left behind. That makes a re-encode a sensible final pass on a file whose history you are unsure about. Its built-in check is a heuristic, not a parse: 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. It reports presence, never values, and it has no opinion whatsoever about what is in the picture. A cropped area stored inside a Word file, a slide deck or a PDF is outside what it can open, and a detail still visible in the frame is outside what any header tool can touch. The tool handles its layer; the crop is yours to make real.

Related guides

See also:

• Does cropping a photo remove GPS metadata too?
• What metadata does a screenshot contain?