privacy · redaction · security · how-to
How to redact an image so data cannot be recovered
Why blur, pixelation, and overlaid shapes leak confidential data, how layers betray redactions, and a verified procedure for irreversible sanitization.
Redaction failures usually stem from a simple confusion: visual occlusion is not data deletion. A black bar drawn across text hides the characters from casual view, but if underlying vector objects, raster layers, or file metadata persist, an external party can extract the contents immediately.
Hiding puts something over the data. Removing replaces the data. If the original pixels still exist anywhere in the delivered file, in a layer, in an annotation object, in an embedded thumbnail, the redaction has been rendered rather than performed. Nearly every published failure is a variant of that one mistake.
Why common methods leak data
Black rectangles and layers
A solid opaque rectangle written into the pixel data is irreversible. The original values are overwritten, and no algorithm recovers them, because they are no longer in the file. This is the strongest method available, which is why it is worth understanding how it fails.
The failures happen during file encoding, not during the drawing:
- Layered image formats (PSD, multi-layer TIFF, SVG): Drawing a rectangle on a new layer leaves the original pixel layer underneath intact. Opening the file and toggling layer visibility reveals the data.
- PDF annotation overlays: Adding a black rectangle via PDF markup tools inserts an annotation object above the text stream. The underlying character text remains selectable, searchable, and extractable by PDF parsers.
- Word processing and slide documents: Shapes overlaid on pasted screenshots remain movable vector objects.
Flattening is the step that turns a drawn box into a redaction. Always export the final sanitized document to a flat raster format (PNG or JPEG) to merge and overwrite the pixel grid.
Gaussian blur
Gaussian blur applies a mathematical convolution across a pixel radius. For facial images at sufficient radii, blur destroys identifying structure.
For typography, blur provides weak protection. Text draws from a small, deterministic character set with known font geometries. Attack tools render candidate strings with the target blur radius and compare pixel matrices against the blurred image. If character spacing or word boundaries remain visible, matching algorithms reconstruct the text.
The practical test: if the rhythm of light and dark still shows where one word ends and the next begins, the radius is too small to resist that attack. A blur strong enough to protect text turns whole phrases into a featureless smear, at which point a solid fill would have been simpler and safer.
Pixelation
Pixelation replaces groups of pixels with their mean colour value. That mean is a real measurement of the original content, and because the pixel grid stays regular, the search space for brute-force matching against known fonts is smaller than with Gaussian blur.
Automated tools defeat pixelated text reliably. For sensitive numbers, passwords, and names, avoid pixelation. It also offers less than it appears to for faces: it defeats casual recognition, but not a determined attempt against a small known set of candidates, such as the staff of one company. Treat pixelation as a visual convention announcing that something is hidden, not as a protection.
Cropping
When sensitive data sits near image borders, cropping eliminates the pixels entirely. Nothing outperforms deleting the data, and a crop leaves no artefacts for an attacker to analyse.
Confirm the editor exports a flat file rather than saving non-destructive crop coordinates in file metadata. Some editors and most raw workflows keep the full frame and record the crop as an instruction. Check that the exported dimensions actually changed.

Secondary disclosure risks in image files
Sanitizing the primary canvas does not clear all sensitive image data:
EXIF and XMP metadata. Camera and phone photos record capture time, camera serial numbers, editing software histories, and GPS coordinates accurate to a few metres. Redacting a face in a photo while leaving those coordinates in the EXIF block exposes the location where the photo was taken.
Strip all metadata before publishing. OpusImg's image compressor strips EXIF tags by default.
Embedded EXIF preview thumbnails. Camera firmware often generates a miniature JPEG thumbnail inside the EXIF header. Many photo editing programs modify the main image canvas without updating the embedded thumbnail. Anyone inspecting the EXIF segment can view the unredacted thumbnail. Stripping metadata removes the stale preview along with everything else, which is the second reason to treat that step as mandatory.
Reflections and background details. Check secondary reflective surfaces within the frame: computer screens, glass windows, bathroom mirrors, and identification badges hanging from lanyards.
Contextual inferences. Redacting an executive's name while leaving an office room number or distinctive calendar schedule in the background allows viewers to deduce identity. Redaction protects pixels. It does not protect against inference.
Screenshot exposure risks
Screenshots represent the most common accidental data disclosure in engineering and operations workflows:
- Authorization tokens, bearer cookies, and API keys displayed in terminal sessions or browser network panels.
- Customer records, email addresses, and payment IDs visible in administration panels.
- Internal staging URLs, VPN endpoints, and directory paths.
- Open browser tab titles visible across the top application bar, which routinely disclose more than the tab being demonstrated.
- Colleagues' names in a sidebar, a chat list, or a notification banner that arrived mid-capture.
One failure deserves naming on its own: people redact a screenshot by uploading the unredacted original to a free online blur tool. The first step of protecting the data discloses it to a third party, which is the exact exposure the redaction exists to prevent. Use an in-browser redaction tool that processes the image on your local machine. The wider case for local processing applies here more sharply than anywhere else on the site.
Recommended redaction procedure
- Duplicate the source image. Never apply irreversible operations directly to the sole copy of your original file.
- Crop unneeded context. Remove excess margins and irrelevant UI regions first. Cropping eliminates sensitive peripheral data without requiring manual masking, and it often removes half the problem before any masking begins.
- Apply solid opaque rectangular fills. Draw opaque rectangles directly over sensitive coordinates. Avoid blur or pixelation when obscuring text or identification numbers.
- Export to a flat raster format. Save as PNG or JPEG to merge layers into a unified pixel array.
- Strip metadata. Remove EXIF, XMP, and thumbnail headers as a separate, deliberate step.
- Inspect the output file. Open the saved raster file in a standard viewer to verify that layers and unredacted shapes were removed. Inspect the exported file, not the editor canvas that produced it.
- Run text recognition. Pass the final image through OCR extraction. If the OCR engine extracts any characters from the redacted zones, the obfuscation is insufficient.
Steps 6 and 7 take under a minute and they are the two that get skipped, which is why the failures they catch keep reaching publication.
Verification checks before publishing
- Selection test: In PDF or SVG exports, attempt to drag, highlight, and copy text across the redacted region.
- Extraction test: Run automated optical character recognition across the file to confirm no character patterns survive. This reproduces what an adversary would do first.
- Header inspection: Verify the file size and EXIF tags to confirm thumbnail images and GPS fields were deleted.
When a clean redaction is still not enough
A correct redaction can leak through its own geometry. The position and width of a black bar report the length of a name, the number of line items, and the shape of an address. Where that inference matters, rebuild the image or the document rather than covering parts of it.
Two other cases need a different answer entirely. Evidentiary and legal contexts often require a provably unaltered file, which redaction contradicts by definition; those workflows have their own procedures, and improvising inside them is a mistake. And where the material is commercially valuable and the distribution is wide, assume someone will attempt recovery with tooling rather than eyes. Solid fills, raster flattening, metadata stripping, and an OCR pass over the output are the level of care that assumption earns.
We build the browser-based image tools this guide refers to, which is also how we know where they stop being the right answer.
Tools covered in this article
Keep reading
- Why browser-based image processing is more private than any upload toolWhat happens when you upload an image to a free online tool, why in-browser processing offers a different guarantee, and where the boundary sits.6 September 2026 · 7 min read
- How to compress images with little visible quality loss: a practical guideWhy images are usually far bigger than they need to be, what the quality slider really controls, and a repeatable order of operations that works.6 September 2026 · 7 min read
- DPI, PPI and print size: a practical guideWhy 300 DPI requires physical dimensions to have meaning, what file metadata tags actually do, and how to calculate the pixel dimensions you need for print.6 September 2026 · 7 min read