Blur, pixelate or black box — which redaction actually hides things?

Every photo-redaction tool offers the same three buttons — blur, pixelate, black box — and almost none of them tell you that the three are not equally safe, or that the answer depends on what you’re hiding. This guide is the reasoning behind BlurLocally’s defaults. It’s worth five minutes even if you use a different tool.

The short version

• Text (documents, screenshots, addresses, plates you really need gone): solid black box. Nothing else is certain.
• Faces: strong blur or coarse mosaic both work if the implementation throws pixels away (more below). Black box works trivially but looks brutal.
• When in doubt: the black box has never been reversed, because there is nothing to reverse.

Why pixelated text keeps getting recovered

Pixelation looks destructive — the text becomes unreadable blocks — but each block is just the average color of the pixels underneath. If an attacker knows the font, the font size and the background (all true for screenshots: standard system fonts on white), they can render every candidate character, pixelate their rendering the same way, and compare blocks until the sequence matches. That’s not theoretical. Depix (2020) did it for pixelized screenshots of passwords; Bishop Fox’s Unredacter (2022) extended it and publicly recovered text that had been pixelated specifically as a challenge; academic follow-ups using hidden Markov models improved on both. The attack needs patience, not a supercomputer.

Photographed text — a label shot at an angle in uneven light — is a much harder target than a screenshot, because the attacker no longer knows exactly how each character was rendered. A coarse mosaic on photographed text will usually hold. But “usually” is doing quiet work in that sentence, and the cost of certainty is one click: use the box.

Blur on text fails in a related way. A gaussian blur is a mathematical operation with known structure; deblurring has been a research field for decades, and for text with a known font family the search space collapses the same way it does for mosaic blocks. Cranking blur to absurd strength defeats recovery in practice — but you’re estimating where “absurd enough” begins, and the people writing recovery tools keep moving that line. Boxes don’t negotiate.

Why faces are different

A face isn’t drawn from a 70-character alphabet in a predictable font. There’s no dictionary to brute-force against — the “search space” is every possible face. That structural difference is why a properly implemented blur or mosaic is considered acceptable for face anonymization while being unacceptable for text.

The words “properly implemented” carry weight, though. Two specific failures show up in real tools:

1. The blur is too light. Research groups have repeatedly shown that lightly blurred or small-pixelated faces can be matched against candidate photos by machine learning — a 2016 study matched “obfuscated” faces at rates far above chance when the blur left coarse structure intact. If eyes-nose-mouth geometry survives as smudges, information survives.
2. The effect smears instead of discards. Some blurs are reversible-ish because the original signal is still present, redistributed. The safe construction is a downsample: shrink the face region to a handful of pixels, then scale it back up. Whatever detail existed is gone from the file — there is nothing left to sharpen.

BlurLocally implements both blur and mosaic as downsamples for this reason, and scales the destruction with the size of the region: a face that fills the frame passes through roughly a dozen pixels at default strength. If you use another tool, the honest test is to zoom into the result — if you can still see where the eyes were as distinct dark patches on a large face, turn it up.

One more honest limit: hiding the face hides the face. Tattoos, birthmarks, clothing, a distinctive bag, who’s standing next to whom, and the caption you write are all identifiers that survive any face effect. Redaction is per-element; anonymity is a property of the whole photo.

The layer problem: redaction that isn’t in the pixels

A separate failure class has embarrassed courts, government agencies and companies for twenty years: covering text with a black rectangle on a layer, in a format that keeps layers. PDFs with highlight-style rectangles over text still contain the text — select, copy, paste, done. Image editors that save layered project files, or “annotate” features that store shapes as editable objects, fail the same way.

The defense is flattening: the exported file must be a plain bitmap in which the covered pixels are simply replaced. Every export from BlurLocally is a flat JPEG or PNG re-encoded from raw pixels — there is no layer to peel and no undo baked into the file. If you redact elsewhere, export to a flat image format and, for anything sensitive, re-open the exported file and check what’s actually in it.

Metadata: the redaction next to the redaction

The pixels can be perfect and the file still leaks: EXIF metadata routinely carries the GPS coordinates of where a photo was taken, the capture time and the device. A blurred face on a photo whose metadata says it was taken at your home address is half a redaction. Any export from this site is re-encoded clean, and the metadata guide covers what leaks where in detail.

A decision rule you can remember

If it’s made of characters, box it. If it’s a face, downsample it hard. Then flatten, strip the metadata, and read the caption you’re about to post as carefully as you edited the pixels. That rule survives every published attack we’re aware of as of mid-2026 — and when the next recovery paper lands, the black box will still be boring, ugly and unbeaten.