How to redact a screenshot so the data is actually gone

Redacting a screenshot feels like a solved problem. You blur the account number, you pixelate the customer name, you post it in the ticket. Done.

Except blur and pixelation are not deletion. They are transformations — and transformations can be worked backwards.

Why pixelation leaks

Pixelation replaces each block of pixels with their average colour. That is a deterministic, lossy-but-structured operation, and the structure is the problem.

If an attacker knows the font, the font size, and roughly where the text sat — all of which are visible in the unredacted parts of your screenshot — they can render candidate strings, apply the identical pixelation, and compare the output to your image. Matches identify the original text. Publicly available tooling has demonstrated this against pixelated text.

It works best exactly where it hurts most: short strings from a constrained character set, in a known monospace font. Account numbers. Order IDs. API keys. Anything where the search space is small.

Gaussian blur has the same fundamental weakness. It looks less reversible because it looks messier, but it is still a known transformation applied to a recoverable original.

What actually works

Draw solid, opaque shapes over the content, then flatten and re-export.

Not blur, not mosaic, not reduced opacity. Solid, 100% opaque fill. There is nothing to reverse because the original pixel values are gone — replaced, not rearranged.

Three details people get wrong:

• Opacity must be exactly 100%. A 95%-opaque black box still carries a faint signal of what's underneath, recoverable with a contrast adjustment.
• The redaction must be flattened. If your editor saves layers, the original is still in the file. Export to a flat PNG.
• Cropping is stronger than covering. If the sensitive region is at an edge, crop it off. Removing pixels beats covering them.

The file itself can betray you

Even correct visual redaction can leak through the file format.

In 2023 a class of bug — widely nicknamed "Acropalypse" — affected screenshot editors on more than one platform, including a Google Pixel markup tool and the Windows 11 Snipping Tool. When a user cropped or edited an image and saved over the original, the tool wrote the smaller new file without truncating the old one. The trailing bytes of the original image survived past the end of the new data, and could be recovered.

The visual redaction was fine. The file was not.

Both were patched, and this is not a live vulnerability you need to worry about today. But the lesson generalises: save redacted images as new files, not over the originals, and prefer exporting a fresh file to editing in place.

Metadata is the other quiet channel. Screenshots can carry the capture timestamp, device details, and sometimes the application or window title. If a screenshot is going somewhere genuinely public, strip metadata as a separate step.

A workflow you can actually follow

1. Crop first. Anything you can cut is something you don't have to redact.
2. Cover what remains with solid opaque shapes.
3. Export a new flat file. Never overwrite the source.
4. Reopen the exported file and look at it. This catches the mistake where the shape was on a hidden layer, or you redacted the wrong field.
5. Strip metadata if the destination is public.

The fifth step is optional. The fourth is not — reopening the final artefact is the only check that tests what you actually shipped rather than what you intended.

The thing that's easiest to forget

The screenshots that leak are almost never the ones someone thought carefully about. They're the ones fired off mid-debugging, at speed, with a browser full of tabs and a notification sliding in from the corner.

The strongest habit is not a better blur tool. It is closing the unrelated windows and dismissing notifications before you capture, so there is less to remember to redact afterwards.