Every few months the same story runs again. A court filing, a redacted PDF, a screenshot posted to justify a finding — and someone recovers the text underneath in an afternoon. The names change. The mistake does not: the redaction covered the pixels instead of destroying them.
If you write security reports, this is your problem specifically. You are the person pasting terminal output full of client hostnames into a document that leaves your building.
Pixelation is a reversible function
Pixelation feels destructive because it looks destructive. It is not. Averaging a block of pixels down to one value is a lossy transform, but it is a deterministic one — and determinism is what an attacker needs.
Take an IP address rendered in a known monospace font at a known size. The number of things it could possibly say is tiny: four octets, each 0–255. An attacker renders every candidate, applies the same pixelation, and compares. Whichever candidate produces a matching block of averages is the answer. There is no cryptography here to break. It is a lookup.
The search space is the whole story. Pixelation is only as strong as the number of plausible inputs. An IPv4 address has about 4 billion candidates and structure that prunes almost all of them. A six-character password has fewer. A hostname from a known client has maybe a few hundred. None of those are large numbers to a computer.
This is not theoretical. Tooling to do it has existed publicly for years — Depix
recovers pixelated text from screenshots, and later work like Bishop Fox's
Unredacter demonstrated recovery against the specific advice people were giving at
the time about "safe" pixelation settings. The conclusion from that work is worth stating
plainly: there is no pixel size that makes short, structured text safe.
Why blur is no better
Gaussian blur is a convolution. Convolutions can be inverted — imperfectly, but often well enough — and the same brute-force approach works regardless: render candidate, blur candidate, compare. Blur additionally leaks the length and shape of what it hides. A blurred token still tells you it was 32 characters of hex.
The other failure: covering, not removing
The second class of leak has nothing to do with reversibility and everything to do with layers. Draw a black rectangle over text in a PDF, an image editor, or a slide deck, and you have added an object on top of the text. The text is still in the file. Anyone can select it, or open the file in a tool that ignores your rectangle.
"Flatten it" is the usual advice, and it is sound — but it depends on flattening actually happening, on every export path, every time, including the one your colleague uses at 11pm before a deadline. A control that depends on remembering is not a control.
aCropalypse: the cropped screenshot that wasn't
In 2023, CVE-2023-21036 showed a third variant. Google's Markup tool on Pixel devices — and, in a parallel bug, the Windows Snipping Tool — wrote the cropped PNG over the original file without truncating it. The pixels you cropped away were still sitting in the tail of the file. Years of screenshots that people believed were cropped were recoverable from the file itself.
Nobody involved did anything obviously careless. They cropped an image with the tool their operating system shipped. The failure was that "the visible result looks right" and "the data is gone" were assumed to be the same statement.
What actually works
Only one thing: the original pixels must not exist in the output file.
That means re-encoding the image from a fresh bitmap in which the redacted regions have been overwritten with opaque fill, and writing that out as a new file with metadata stripped — not editing the original in place, not layering, not filtering.
You can check whether a tool does this. Redact something, export, then look at the result with the picture ignored entirely:
# Is the original text still in the file?
strings redacted.png | grep -i "hostname-you-redacted"
# Did metadata survive?
exiftool redacted.png | head -40
# Did the file grow a suspicious tail? (the aCropalypse shape)
ls -l original.png redacted.pngIf the string is there, the redaction is decorative. If EXIF survived, you may have shipped GPS coordinates and a device serial along with your report.
The rule worth internalising
If the original can be recovered from the output, it was never redacted. It was hidden — and hiding is a UI effect, not a security property.
Treat blur and pixelate as what they are: styling. They are appropriate for making a face less identifiable in a marketing screenshot. They are not appropriate for a credential, a hostname, an internal IP, a token, or anything else whose disclosure you would have to report to a client.
This is the reason Blackbar defaults to opaque solid fill and warns you inline before applying a reversible style to something it has classified as a secret. Export rasterises the source, overwrites the redacted regions in the bitmap, encodes a brand-new image, and strips all metadata — and a test in the build suite reads exported files back and asserts the original content is gone. Not because that is clever, but because it is the only behaviour that survives the check above.