Why blurring and pixelating are not safe redaction

You screenshot a support ticket, blur the customer's email and card number, and share it. It looks gone. But "looks gone" and "is gone" are two very different things. Blur and pixelation frequently leave enough signal behind to reconstruct the original text, and there have been real, public cases of "redacted" documents being un-redacted. This article explains why, and what actually makes a redaction irreversible.

Redaction means destroying information, not hiding it

The core mistake is treating redaction as a visual effect. A blur or a mosaic is a reversible transformation: it rearranges the pixels according to a known formula. If the transformation is reversible, the information is still there, just scrambled. Real redaction removes the underlying data so there's nothing left to recover.

Why blur can be reversed

A Gaussian blur convolves each pixel with its neighbours using a known kernel. Because the operation is mathematically defined, it can be approximately inverted (deconvolution), especially when the attacker can guess the parameters. It gets worse for text:

• Known font and layout. Screenshots use standard system fonts at standard sizes. An attacker can render every candidate string with the same font, blur it identically, and compare. The closest match wins.
• Limited character set. A card number is 16 digits; a date has a fixed format. Small search spaces are trivial to brute-force against a blurred target.
• Weak blur radius. A blur that still lets you perceive the shape of the text lets a model perceive it too.

Why pixelation and mosaic can be reversed

Pixelation averages each block of pixels into one value. Given a known font and charset, an attacker can pixelate every candidate string with the same block grid and match it against the mosaic. This is exactly how tools like Depix recover pixelated text. Mosaic feels destructive, but it's really just a lossy, invertible encoding of the same limited-entropy content.

The other leak: hidden layers and metadata

Even a perfect visual redaction fails if the original data still ships inside the file:

• Vector "black boxes". Drawing a black rectangle over text in a PDF or design tool adds a layer on top, and the text underneath is untouched and can be copied out or deleted. Countless leaks have come from exactly this.
• Embedded thumbnails and EXIF. Many cameras and editors store a small preview of the original image in the file's metadata. Redact the main image, forget the thumbnail, and you've shipped the secret anyway.
• Undo history or original alongside output. If your workflow keeps the un-redacted original next to the masked copy, one wrong file exfiltrated undoes everything.

What actually works

• Overwrite the pixels with a solid fill. A solid box that replaces the region with one opaque colour destroys the information. There's nothing to deconvolve or brute-force.
• Flatten to a single-layer raster. Export to a flat format like PNG so there are no layers to peel back and no selectable text underneath.
• Strip metadata. Re-encode the image so embedded thumbnails and EXIF from the source don't survive.
• Over-cover slightly. Tight boxes can leave antialiased glyph edges peeking out; a small safety margin removes that fringe.

How Privshot handles it

Privshot's default style is a solid box that overwrites the pixels, the only truly irreversible option. The result is exported as a flat PNG (via a canvas in the web tool, or a re-encoded image in the API), so there are no hidden layers and the source's EXIF and thumbnail metadata don't carry over. Every region is also grown by a small safety margin so a tight detection box can't leak glyph edges.

We also offer blur and pixelate because they're sometimes preferred for readability or aesthetics, but we're honest that they are not a guarantee against reconstruction. For anything sensitive, use a solid box. You can see every option in the API docs.