How to redact an image so the data is actually gone

Redaction failures make the news for a reason: the document looks redacted. The black box is right there. And the text underneath is recoverable in thirty seconds by someone who knows one thing you did not.

Image redaction has the same failure modes as document redaction, plus a few of its own. Here is what actually removes information and what merely hides it.

The distinction that matters

Hiding puts something over the data. Removing replaces the data.

If the original pixels still exist anywhere in the file — in a layer, in a metadata thumbnail, in an object underneath a drawn rectangle, in an undo history — the redaction has not happened. It has been rendered.

Nearly every real-world failure is a variant of this: someone hid the information convincingly and never removed it.

Method by method, and what survives each

Black boxes: correct, if done correctly

A solid opaque rectangle drawn into the pixel data is genuinely irreversible. The original values are overwritten. There is no algorithm that recovers them because they are not there.

This is the strongest method and it is also where the classic failures happen — not because the technique is weak, but because of how the box was applied:

• A rectangle drawn in a layered editor and saved to a layered format keeps the original pixels in the layer below. Anyone opening the file can hide the top layer.
• A rectangle drawn in a PDF annotation tool is an object over the content stream. The text is still text. It selects, it copies, it is extracted by any parser.
• A rectangle drawn in a slide deck or word processor is a shape. Move it and the content is there.

Flattening is what turns a drawn box into a redaction. Export to a flat raster format — PNG or JPEG — and confirm you are looking at pixels, not objects.

Blur: recoverable in principle, weak in practice

A Gaussian blur is a mathematical convolution. It is not encryption, but it does destroy information — the question is how much.

For a face at reasonable size, a strong blur is genuinely destructive. For text, it frequently is not. Text has a small, known alphabet and rigid structure. Given the blur radius, an attacker can render every candidate character with the same blur and match against the image. This is a well-established technique and it works on real documents.

If you must use blur, use a radius large enough that entire words become a featureless smear rather than a rhythm of light and dark. If you can still see where the word boundaries are, so can the matching attack.

Pixelation: the weakest of the three

Pixelation replaces each block with its average colour. That average is a real measurement of the original content, and there are only so many things that could have produced it.

For text, it is close to useless as a defence: the same rendering attack works, and it works better than against blur because the block structure is regular and the search space smaller.

For faces, pixelation defeats casual recognition but is not a serious protection against a determined attempt, particularly when the person is one of a small known set — a colleague in a company photo, someone identifiable from context.

Pixelation is a visual convention that says "something is hidden here". It should not be relied upon when it matters.

Cropping: excellent, and underused

If the sensitive content is at the edge of the image, cropping it away is total removal with no residue and no artefacts to analyse. Nothing beats deleting the pixels.

The caveat is that some formats and workflows retain the pre-crop data — non-destructive crops in editors, and some raw workflows. Export to a flat format and verify the dimensions changed.

The problems specific to images

Beyond the redaction itself, image files carry sensitive data in places that a black box does not touch.

Metadata. EXIF in a camera or phone JPEG can include GPS coordinates to a few metres, the exact capture time, the device serial number, and the software used to edit it. XMP can carry author names, copyright, and editing history. Redacting a face in a photograph and publishing the file with the coordinates of where it was taken is a common and complete failure.

Strip metadata as a separate, deliberate step. Most compressors do it by default — compressing the final image is a reasonable way to guarantee it, provided you confirm the tool actually strips rather than preserves.

Embedded thumbnails. This is the most under-known risk. Many camera JPEGs contain a small preview image inside the EXIF block. Some editors update the main image and leave the thumbnail stale. The result is a file whose full-size version is redacted and whose embedded preview shows the original — a documented failure mode with real incidents behind it.

Stripping metadata removes the thumbnail along with everything else, which is another reason to treat that step as mandatory rather than optional.

Reflections and secondary appearances. The information you redacted may appear elsewhere in the frame: a name badge reflected in a monitor, a screen visible in a window, a document partly showing at the edge of the desk, a mirror. Scan the whole image, not just the obvious region.

Context. A redacted name in a photograph of a single office door, with the room number visible, is not redacted in any meaningful sense. Redaction protects the pixels; it does not protect against inference.

Screenshots deserve their own section

Screenshots are the most frequently shared and least carefully redacted images in professional life, and they are dense with incidental disclosure:

• API keys and bearer tokens in a network panel or a terminal.
• Customer names, email addresses and account identifiers in a table.
• Internal hostnames, ticket numbers and repository paths.
• Colleagues' names in a sidebar, a chat list, or a notification.
• The browser tab strip, which often reveals more than the tab you meant to show.
• The clock and battery, which can matter more than expected in a timeline dispute.

And a self-inflicted one worth naming: people frequently redact a screenshot by uploading the unredacted original to a free online blur tool. The first step of protecting the data is disclosing it to a third party. If you take nothing else from this article, take that — redaction is a task that should run on your own device, because the alternative defeats its own purpose. The wider argument for local processing applies here more sharply than anywhere else.

A procedure that holds up

1. Work from a copy. Keep the original somewhere private; you may need it, and you must not redact in place.
2. Crop first. Remove everything outside the region you actually need to show. This is free, total removal, and it often eliminates half the sensitive content before you start.
3. Cover the remaining regions with solid opaque fills, drawn into the pixels. Not blur, not pixelation, unless you have a specific reason.
4. Flatten to a raster format. Export as PNG or JPEG. This is the step that converts drawn objects into pixels and discards layers.
5. Strip metadata. Separately and deliberately. Verify rather than assume.
6. Reopen the exported file and inspect it. Not the editor's canvas — the actual output file, opened fresh.
7. Check for extraction. Run OCR over the final image and read what comes back. If any redacted text appears, the redaction failed. This is a thirty-second check that catches the exact class of failure that makes headlines.
8. Re-read the whole image for context and secondary appearances. Reflections, edges, the tab strip, anything inferable.

Steps 6 and 7 are the ones people skip, and they are the ones that catch the failures.

Verification, specifically

Three checks, in order of how much they catch:

Select and copy. In the final file, try to select text over a redacted region. In a raster image you cannot, which is one of the reasons flattening to raster is a strong move. If you are delivering a PDF, this check is essential and it is where PDF redaction most often fails.

Extract. Run text extraction over the final file. An OCR pass tells you what a machine can read from your output — which is precisely what an adversary would do.

Inspect the file. Open the exported image in a metadata viewer. Confirm EXIF is gone, confirm there is no embedded thumbnail, confirm the dimensions match the crop.

When redaction is not enough

Some situations need more than a good redaction.

If the recipient must not be able to tell what was removed, note that the shape and position of a black box leaks information — the length of a name, the number of line items, the structure of an address. Consider reconstructing the image or the document rather than covering parts of it.

If the image must be provably unaltered, redaction conflicts with that requirement. Legal and evidentiary contexts usually have their own procedures, and improvising is a bad idea.

If the data is high-value and the distribution is wide, assume someone will attempt recovery. Solid fills and flattening, with the verification steps, is the level of care that assumption deserves — not a blur applied by eye.

The one-sentence version

Redaction works when the original pixels no longer exist in the delivered file — so cover with opaque fills, flatten to raster, strip the metadata, and then verify by trying to extract what you removed.

Everything that goes wrong is a case of the pixels still being there somewhere: in a layer, in an annotation object, in a thumbnail, or in a blur that preserved more than it destroyed.