How to redact an image safely: blur, pixelation or solid coverage?

Blurring and pixelation transform information instead of removing it, and both have been reversed in published research. What actually works, and what still leaks after you have covered the obvious.

Published 2 August 2026

There’s a comfortable assumption behind most redaction: if you can’t read it, nobody can. It’s wrong often enough, and in a specific enough way, that it’s worth understanding before you publish a screenshot with your bank details blurred out.

Short version: a solid block removes information, while blur and pixelation only rearrange it. Everything else follows from that.

Why blur and pixelation are recoverable in principle

Both are deterministic transformations. Pixelation divides a region into blocks and replaces each one with the average colour of the pixels inside it. Blur replaces each pixel with a weighted average of its neighbours. Either way the output is a function of the original pixels. Reduced, yes, but derived from them and not discarded.

That opens a straightforward attack whenever the space of possible originals is small. Say an account number has been pixelated. An attacker who knows the font, the size and roughly the position can render every candidate string, apply the same pixelation, and compare against the published image. Whichever candidate matches is the answer. No clever inversion needed: it’s a search over a small space, checked by a cheap forward operation.

None of this is hypothetical. Hill, Zhou, Saul and Shacham demonstrated it systematically against mosaiced and blurred text in a 2016 paper for the Privacy Enhancing Technologies Symposium, recovering redacted content at high rates. Open-source tools automating the same idea against pixelated screenshots have been public since 2020.

When the attack works, and when it doesn’t

The technique depends on the attacker being able to narrow the candidates. That makes it strong in precisely the cases people most often redact:

Text in a known font. Screenshots of interfaces and documents are the worst case, because the font, size and rendering are all predictable.
Short, structured strings. Account numbers, licence plates, postcodes, dates, six-digit codes. A small search space is a solved search space.
Anything with a checksum. Card numbers and IBANs let an attacker throw out most candidates immediately.

It’s much weaker where the space genuinely is large:

Faces, where the candidate set is every person alive. Blur does meaningfully degrade identification here, though it isn’t nothing: a low-resolution face still carries pose, hair, skin tone and setting, and modern matching works on far less than we tend to assume.
Unstructured natural images with no known reference.

Notice how that cuts, though. The cases where blur is weakest are the cases where redaction usually matters most.

Coverage strength, ranked

Solid fill. The pixels get replaced with a constant. The output doesn’t depend on the input, so there’s nothing to invert. The information is gone in the mathematical sense, not merely obscured. This is the only option to use for anything that matters.

Heavy pixelation. Better than light pixelation, and still a function of the original. Larger blocks throw away more, so there’s a point where recovery becomes impractical, but you can’t easily tell from looking where that point is. Don’t try to judge it by eye.

Blur. The weakest of the three. A Gaussian blur is invertible in principle, since the operation is a convolution and deconvolution is a well-studied problem. Noise and clipping make perfect inversion hard in practice, but hard isn’t impossible, and partial recovery is often plenty.

Reducing opacity. Not redaction at all, though people attempt it surprisingly often. The original is still sitting there at reduced contrast, and a levels adjustment brings it back in seconds.

The failure that has nothing to do with the algorithm

The most common real-world redaction failure isn’t a broken blur. It’s a covering that was never part of the pixels.

Draw a black rectangle in a PDF editor, a word processor or a vector tool and you’ve added an object on top of the content. The content is still in the file. Selecting the text underneath, copying it, or opening the file in a different program frequently brings it back, and this has caused real disclosures in court filings and government releases repeatedly, for decades.

The defence is easy to state: redaction has to be destructive, and it has to happen at the pixel level. Export a flattened raster image. If your tool produces a file where the covering is a separate, selectable object, it hasn’t redacted anything.

Taking a screenshot of a redacted document is a crude but effective way to flatten it, which is why that advice persists.

What’s still leaking after you’ve covered the obvious

Covering the sensitive region is necessary. It isn’t sufficient.

Metadata. Photographs carry EXIF, which routinely includes GPS coordinates, the camera or phone model, and a timestamp. Screenshots carry less but often still record the device and software. Re-encoding an image through a canvas, which is what exporting from a browser-based tool does, drops all of that as a side effect. Only if the export genuinely re-encodes, though, rather than passing the original file through.

The parts of the frame you didn’t consider. Reflections in glasses, screens and windows. A shop window behind you. A parcel label in the background. A wall calendar. Browser tabs, a taskbar clock, the notification you didn’t notice, an autocomplete dropdown, a bookmark bar full of internal URLs.

The shape of what you covered. A redaction block sized exactly to its content leaks the length of the string, and sometimes that’s decisive: six characters versus eleven narrows a name considerably. Where it matters, oversize the block, or make every block the same size.

Structural clues. A partially redacted date with only the year covered. A masked email with the domain left visible. Consistent redaction across several documents, where same-length blocks let an attacker line them up.

Thumbnails and previews. Some formats embed a small copy of the image, and some editors update the main image while leaving the embedded preview alone. Re-encoding removes the embedded copy entirely.

A procedure that holds up

Work from a copy. Never redact your only original.
Cover with solid fill. Pick blur or pixelation only when appearance matters more than the secrecy does, and be honest with yourself about which one you’re in.
Oversize the blocks so they don’t trace the shape of the content.
Zoom in and sweep the whole frame, not just the part you were thinking about. Reflections, backgrounds, edges.
Export a flattened raster file. Not a PDF with a shape on top, not a layered file.
Re-open the exported file, the one you’re actually going to send, and check it. Try selecting text in it. Look at its metadata.
Think about what the recipient already knows. Redaction protects against a reader who lacks context, not one who has most of it already.

The honest limit

No tool can tell you whether a redaction is sufficient, because sufficiency depends on what the attacker already knows and the tool has no way to know that. What a tool can do is remove the information instead of disguising it, be explicit about which of those it’s doing, and flatten the output so the covering can’t be peeled off.

That’s the bar worth holding any redaction tool to, the one here included. It uses solid fill as its default for the reasons above, and says plainly that its blur and pixelation options are the weaker choice.

Sources and further reading

Last reviewed 2 August 2026.