Why blurring sensitive text isn't enough

The mistake that keeps happening

Someone posts a screenshot with an account number blurred out, or shares a slide where a salary table is pixelated. It looks hidden. Weeks later, the number is public — because the obscuring was reversed.

This isn't hypothetical. Security researchers have repeatedly demonstrated recovery of pixelated text, and open-source tooling exists that does it semi-automatically for common cases. The failure isn't in any one product; it's in the technique itself.

What blur and pixelation actually do

Blurring and pixelation don't remove information — they redistribute it. A blur replaces each pixel with a weighted average of its neighbours. Pixelation (mosaic) replaces each block of pixels with the block's average color. In both cases, the output pixels are mathematically derived from the secret pixels. Some of the original information is destroyed, but a lot of it survives, smeared across the region.

That surviving information is the attack surface. If the attacker can guess the setting — a known font, a known character set like digits, a fixed layout like a credit-card field — they can render every candidate string, apply the same pixelation, and compare the result to your image. When a candidate's pixelated version matches, they've recovered your text. This is how depix-style attacks work conceptually: it's not magic un-blurring, it's a guided guessing game that the leaked averages make winnable.

Text is especially vulnerable because it's low-entropy: limited character sets, known fonts, predictable sizes and positions. A pixelated face in a crowd is one problem; a pixelated password in a terminal screenshot with a known monospace font is close to a solved puzzle.

What secure redaction means

Secure redaction is destruction, not disguise. Every pixel in the sensitive region is replaced with a constant color — solid black, solid white, anything constant. The output pixels have zero mathematical relationship to the original pixels. There is nothing to invert, average, or brute-force, because the information is simply not present in the file anymore.

The visual result is less pretty than a tasteful blur. That's the point. A solid rectangle communicates 'something was removed here' honestly, and it's the only version of that message that's actually true.

The second trap: editing that doesn't stick

Even solid rectangles fail when the editing tool preserves the original underneath. Classic failure modes include drawing a black box as a separate layer in a format that keeps layers, exporting a PDF where the rectangle is an annotation floating above intact text, and images whose embedded metadata thumbnail still shows the unedited original.

The safe pattern is flattening: the final image should be rasterized into brand-new pixels, so the exported file contains only the merged result, with no layers, no annotation objects, and no leftover metadata previews.

How to do this locally

Our Redact Image tool implements the safe pattern end to end, in your browser. Solid modes are labelled secure redaction; blur and pixelate exist for cosmetic use but carry a persistent warning and a one-click 'convert all to secure' button. At export, the image is rasterized into fresh pixels, and the tool then re-decodes its own output and samples every secure region to confirm the pixels exactly match the replacement color. Because the pipeline re-encodes from a clean canvas, EXIF metadata — including embedded preview thumbnails — is not carried into the output. If verification fails, the download is blocked instead of being labelled safe.