security
Why Blurring or Pixelating a Screenshot Doesn't Actually Redact It
Pixelation and blur look like they destroy text, but both are reversible under the right conditions. What Depix and Unredacter proved, why Gaussian blur is just as unsafe, and what actually hides a secret.
Someone shares a screenshot with an API key smudged out, feels good about it, and posts it publicly. The smudge is not a wall — it’s a puzzle, and the pieces are still all there. Pixelation and blur don’t delete information, they scramble it in a mathematically predictable way, and for text specifically, that scrambling has already been broken by public tools more than once.
How pixelation actually works
Pixelating a region doesn’t destroy the pixels underneath — it averages them. A pixelation filter divides the selected area into blocks (say, 8×8 or 12×12), computes the average color of each block, and replaces every pixel in that block with the average. The original detail is gone from any single block in isolation, but the process is deterministic and public. Anyone who knows the block size and averaging method can reason backward: not perfectly, but far better than “gone.”
That backward reasoning is trivial for a photo of a face, where the possible source images are effectively infinite. It’s a very different problem for a screenshot of text, where the source is constrained to a tiny alphabet of characters rendered in a known font at a known size. Constrain the search space that hard, and “irreversible” stops being true.
Depix: the tool that broke pixelated passwords
In 2020, a researcher accidentally saw a screenshot with a Domain Admin password pixelated out — the kind of credential that controls an entire corporate network — and built Depix to see if it was recoverable. It was.
Depix works by generating a reference image containing every possible character rendered in the same font, using a De Bruijn sequence so every pair of adjacent characters appears somewhere in the reference. It pixelates that reference the same way the target image was pixelated, then matches each pixelated block from the screenshot against the reference blocks. Enough matches, stitched together with positional constraints, and the plaintext falls out.
The catch, and the reason Depix has real limits: it only works cleanly against a linear box filter — literal block averaging with hard edges — and it needs surrounding context to anchor the font and block grid. Change the filter, and Depix’s exact matching approach struggles.
Unredacter: closing the gap Depix left open
Bishop Fox’s Unredacter, released in 2022 by researcher Dan Petro, went further. Instead of requiring an exact filter match, it uses the unredacted text elsewhere in the same document to learn the font, size, and rendering, then runs an optimization search: render candidate strings, pixelate them the same way, and see which candidate produces the closest match to the pixelated block. That approach is far more tolerant of exactly how the pixelation was applied, which is precisely why Bishop Fox titled the writeup “Never Use Text Pixelation to Redact Sensitive Information.”
Two independent tools, two years apart, both proving the same thing: pixelated text is a solvable puzzle, not a deletion.
Faces aren’t safe either
You might assume this is a text-only problem — that pixelating or blurring a face, where the “alphabet” isn’t constrained to characters, is genuinely safe. The Fantômas research (PoPETs 2024) tested this directly against 15 face anonymization techniques using deep-learning reconstruction attacks and found 11 of the 15 were at least partially reversible — including Gaussian blur, which the researchers found only obfuscates identifying information rather than removing it. The techniques that actually held up were the ones that generate an entirely new synthetic face to replace the original, not ones that distort the existing one.
The pattern holds across both domains: any transformation that keeps a mathematical relationship to the original — averaging, blurring, shuffling blocks — leaves that relationship available to an attacker with enough patience or compute. Only replacing the region with something that has no relationship to the source is safe.
The separate trap: black-box redaction in PDFs and screenshots
There’s a second failure mode that has nothing to do with blur or pixelation math, and it’s caused real damage: drawing an opaque black rectangle on top of intact text instead of removing the text itself. The rectangle covers the rendering, but the underlying text layer is untouched — still selectable, searchable, and copyable.
This isn’t hypothetical:
- In the 2019 Paul Manafort case, a Guardian reporter copy-pasted “redacted” text straight out of a court filing’s black boxes and published what the defense had tried to keep sealed.
- Samsung’s confidential licensing terms leaked out of supposedly redacted filings in litigation with Apple the same way.
- When the DOJ released the Epstein files in December 2025, social media lit up with a one-step “exploit”: highlight the black bar, hit Ctrl+C.
Same root cause every time — a shape drawn over content is not the same as removing the content. We go deep on the PDF version of this specifically — why the black box leaves the text layer intact and what actually removes it — in Black Boxes Don’t Redact PDFs.
Decision table: what’s actually safe
| Method | Hides from a casual glance? | Survives a determined attacker? | Use it for |
|---|---|---|---|
| Gaussian blur | Yes | No — partially reversible even for faces | Aesthetic effect, background de-emphasis |
| Pixelation / mosaic | Yes | No — broken for text by Depix and Unredacter | Aesthetic effect, casual “don’t stare at this” |
| Black box drawn over text | Yes, visually | No — underlying text/pixels often still present | Nothing you actually care about |
| Solid blackout that replaces the pixels (not an overlay) | Yes | Yes | Real secrets: passwords, API keys, account numbers |
| Full crop / removal of the region | Yes | Yes | Anything, including the pixels you’d otherwise redact |
The rule that falls out of all of this: if you actually need to hide something — a password in a screenshot, an account number, a face tied to a legal case — replace the pixels, don’t distort them. A solid fill or a crop can’t be reasoned backward from, because there’s no relationship left to exploit.
Redact it right, and check what else you’re exposing
The Blur / Pixelate / Redact Image tool supports actual blackout fills, not just blur and pixelate — draw the box, fill it solid, and the tool warns you when you’re about to ship a blur or pixelate over something that looks like it might be a secret. Everything runs in your browser; the screenshot never gets uploaded anywhere, which matters doubly for an image you’re specifically trying to make safer to share.
Pixels are only half the leak, though. A screenshot or photo you think you’ve cleaned up visually can still be carrying a GPS location, device model, and timestamp in its metadata — invisible in the image itself, sitting in the file. We cover exactly what that looks like and how to check it in Does Your Photo Leak Your Home Address? How EXIF and GPS Metadata Work. Between the two, redacting the visible content and stripping the invisible metadata, that’s the actual bar for “safe to share” — not a blur filter and a hope.
And when the thing you’re sharing is text rather than an image — a log, a support ticket, a prompt — the failure mode inverts: the redaction works fine, but pattern matching simply cannot find names, addresses, or dates of birth. Why regex PII redaction always leaks covers where automated scrubbing genuinely helps and where you still have to read the output yourself.