Can blurred text be recovered? Yes — and it is easier than you think

Someone asks you for a screenshot. It has an API key in it, or a customer’s email address, or a colleague’s salary. You drag the blur tool over the offending rectangle, watch it dissolve into a soft smear, and send the file.

The smear is not a deletion. It is an arithmetic operation, and arithmetic operations can be run backwards.

Blur does not remove information, it redistributes it

A Gaussian blur replaces every pixel with a weighted average of its neighbours. That is the whole operation. The pixel that used to be the sharp black stroke of a 7 is now a mixture of that stroke and the white space around it — but the stroke’s contribution is still in there, spread across the neighbouring pixels rather than thrown away.

Because the operation is a convolution with a known kernel, it has an inverse. Given the blurred output and a good guess at the blur radius, deconvolution reconstructs an approximation of the input. This is not exotic research code; it is a standard tool in astronomy and microscopy, where the entire point is recovering detail that an optical system smeared.

The practical difficulty is estimating the radius. That difficulty lasts about as long as it takes to try every radius from 1 to 40 and look at which output contains readable text.

Pixelation is worse, not better

Pixelation feels safer because it looks more destructive — big flat blocks, no soft gradient, apparently nothing left. In fact it leaks in a way that is far more tractable to attack.

Pixelating a region means dividing it into cells and setting each cell to the average colour of the pixels inside it. So each block is a precise, honest measurement: the mean brightness of this 8×8 area of the original.

Now consider what is being hidden. Screenshots contain text, and text on a screen is rendered from a small set of fonts, at a small set of sizes, with a small set of foreground and background colours. An attacker can therefore:

1. Render a candidate string — say, every possible 16-digit card number prefix — in the same font, size and colour.
2. Apply the identical pixelation grid to each candidate.
3. Compare the resulting block averages to the blocks in your screenshot.

The candidate whose averages match is the original string. This is not deblurring at all; it is a brute-force search against a very small space, and it is exact rather than approximate. Published tooling has demonstrated this against pixelated screenshots for years.

The narrower the space of possible values, the more complete the failure. A pixelated six-digit verification code is not obscured in any meaningful sense.

Why “it looks unreadable to me” is the wrong test

The eye is a poor detector for this. You are looking at a smear at 100% zoom on a bright display and concluding that the information is gone. What actually matters is how much of the original signal survived in the file, and that is a question about pixel values, not about perception.

There is a stricter test, and it is the one worth adopting:

After redaction, the pixels under the redacted region must be independent of what was there before. If two different originals could not produce two different outputs, the redaction holds.

Blur fails this test. Pixelation fails this test. A solid opaque fill passes it, because every original maps to the same flat block of colour — the mapping is many-to-one and cannot be inverted.

The other way this goes wrong: the pixels were never touched

Even a solid black box can fail, for a completely different reason. If the box is a layer rather than a change to the image, the original pixels are still in the file underneath it.

This is the failure mode behind most of the famous redaction leaks:

• A PDF with a black rectangle drawn over text, where the text object is still in the content stream and comes out with copy-paste.
• An Office document where the shape sits above the content and is deleted by dragging it aside.
• An image editor’s project file — .psd, .xcf, .kra — where the redaction is a layer and the background layer is untouched.
• A screenshot annotated in a tool that stores annotations as vector objects and only flattens them on export, where sharing the project file shares everything.

And one more that is specific to screenshots, and easy to miss: the file you send is often not the file you edited. If the tool auto-saves the original before you redact it, or writes a crash-recovery copy, or keeps an undo history in a sidecar file, then an unredacted version exists on disk even though the exported PNG is clean.

What actually works

Use a solid, fully opaque fill. Not 90% opacity — a fill at 90% opacity leaves 10% of the original signal, which a levels adjustment pulls straight back out. Fully opaque, or it is not redaction.

Flatten before you share. Export to PNG or JPEG so there is one raster layer and no object model. Do not send the project file.

Crop rather than cover, when you can. If the sensitive region is at the edge, cutting it off removes the pixels rather than replacing them, and there is nothing to argue about.

Check the result, not the editor. Open the exported file in a different program, zoom to 400%, and raise the brightness and contrast hard. If anything resolves, the redaction did not hold.

Retake the screenshot when the stakes are high. Blur the data in the application itself — use a demo account, a seeded test database, or the browser’s element inspector to replace the text — and then capture. The safest sensitive pixel is one that was never written to a file.

Where SnapShield AI fits

We built SnapShield AI around the strict test above. Its redaction replaces the pixels in the exported image rather than drawing over them, and everything runs on your machine — the image is never uploaded to a server for processing, which matters when the thing you are trying to redact is exactly the thing you do not want to transmit.

We take this seriously enough to have shipped a security release over it. In an earlier build, our own solid redaction was drawn at 90% opacity and could be recovered with a levels adjustment, and the blur tool applied a plain Gaussian. Both were fixed in 1.6.2, and the behaviour is now covered by pixel-level tests that fail the build if a redacted region correlates with what was underneath. If you shared anything redacted with a build before 1.6.2, treat it as unredacted and redo it.

That is the standard to hold any redaction tool to, including ours: not “does it look gone”, but “can you prove the pixels changed”.

Related reading

• How to redact a screenshot on Windows — the practical steps in Snipping Tool, Paint and SnapShield.
• Redacting screenshots for GDPR — what regulators expect when a screenshot contains someone else’s data.
• I ran deconvolution on my own redaction output — the theory above, measured: what actually came back, and what did not.