Why most redaction fails
The recurring redaction failure is not that someone forgot to cover something. It is that they covered it in a way that was never actually removal. A black rectangle drawn over text in a PDF is an annotation sitting on top of a text layer that is still fully present in the file — selectable, copyable, and recoverable by anyone who opens the document in the right tool. The same is true of a shape placed over an image in a slide deck, or a crop that hides part of a photo without discarding the pixels.
This has produced a long series of public embarrassments involving court filings, government disclosures and corporate documents where the covered material was extracted within minutes of publication. In every case the person doing the redacting believed they had removed something, and the file disagreed.
The fix is flattening. Once a redaction is baked into the pixel data and the image is re-encoded, there is no separate layer holding the original, because the original pixels no longer exist in the file. That is what this tool does: whatever you blur, pixelate or cover is composited into a new PNG before it reaches your download folder. There is nothing underneath.
Blur, pixelate, or a solid bar
The three styles are not interchangeable, and the choice matters more than the strength slider.
A solid bar replaces the region. The pixels underneath are gone and nothing about them survives into the output — not their colour, not their arrangement, not a statistical trace. For anything that must not be recoverable under any circumstances, this is the only correct choice: passport numbers, bank details, home addresses, medical information, the face of someone whose identity genuinely must be protected.
Blur and pixelation transform the region instead. A Gaussian blur averages each pixel with its neighbours; pixelation replaces blocks with their average colour. Both destroy a great deal of information and at reasonable strengths are perfectly adequate for ordinary purposes — obscuring bystanders in a street photo, softening a licence plate in a holiday snap, hiding incidental detail in a screenshot.
But both are transformations of the original data rather than replacements of it, and that leaves a theoretical door open. If the underlying content is drawn from a small, predictable set — six digits, a known font, a face from a known group of people — an attacker can generate every candidate, apply the same transformation, and see which one matches. This has been demonstrated against weakly pixelated text more than once. Strength defends against it: the tool starts at settings that are safe for normal use and lets you go substantially higher.
The rule that keeps you out of trouble: aesthetics for faces, solid bars for facts.
What automatic detection does, and what it misses
Dropping an image in starts two passes. A face detector locates faces and proposes a region over each. In parallel, optical character recognition reads the text in the image and flags anything matching a conservative set of sensitive patterns: email addresses, phone numbers, IBANs, payment card numbers, and IP addresses.
Everything found is a proposal, not an action. Regions appear for you to accept, remove or resize, and nothing is applied until you export. That ordering is deliberate — a redaction tool that silently decided what to hide would be both annoying and untrustworthy.
The important limitation is what the pass cannot see. The patterns are intentionally conservative, because a matcher aggressive enough to catch every phone number would also flag every order reference and date. OCR struggles with stylised type, low contrast, handwriting and text at an angle. And a great deal of sensitive information matches no pattern whatsoever: a person's name, a signature, a badge or lanyard, a company logo on a wall, a reflection in a monitor, a distinctive view through a window that places the photograph precisely.
So treat detection as what it is — a fast first pass that catches the structured, high-frequency cases so your attention is free for the rest. Then review the whole image yourself before exporting. The manual rectangle and brush tools exist for everything the automatic pass will never find.
Redacting screenshots and documents
Screenshots are the most common redaction job and the easiest to get wrong, because they carry far more than the thing you meant to show. A screenshot of a dashboard includes the account name in the header. A support-ticket screenshot includes the customer's email in the sidebar. A bank statement screenshot includes the balance you did not intend to share, alongside the transaction you did.
A reliable habit is to work outside in. Start at the edges of the image — browser chrome, tab titles, notification banners, sidebars, footers, breadcrumbs — before looking at the content you are actually there to share. That is where the incidental disclosures live, and it is exactly where the eye does not go, because you have been looking at the middle of that screen all day.
For documents specifically, use solid bars rather than blur. A document screenshot is text in a known font, which is precisely the case where weak obfuscation is most attackable, and there is no aesthetic reason to prefer a blur over a clean black rectangle in a document anyway.
One thing that is easy to forget: redacting a region does not shrink the space it occupied. A solid bar the exact width of a name still tells a reader how long that name was, and a redaction covering a single digit reveals that a single digit was there. When the length itself is revealing, cover a wider region than strictly necessary.
Metadata: the redaction people forget
Obscuring the visible content of a photograph does nothing to the data attached to it. A JPEG from a phone typically carries EXIF metadata recording GPS coordinates accurate to a few metres, the exact date and time, the device model and sometimes its serial number, and occasionally a thumbnail of the original image generated before any editing.
That last one deserves emphasis. Some editing workflows update the visible image while leaving a stale embedded thumbnail in place, which means a carefully redacted photo can travel with a small unredacted copy of itself inside the file. It is a real class of disclosure, not a hypothetical.
Exporting from this tool sidesteps all of it. The redacted image is composited onto a fresh canvas and encoded as a new PNG, so nothing from the original file's metadata carries into the output — no GPS, no timestamps, no device identifiers, no embedded thumbnail. You get an image that contains the pixels you approved and nothing else.
If you are redacting a photograph for publication, this matters as much as the visible redaction. Blurring a face in an image whose metadata names the street where it was taken has not protected anyone.
Everything runs on your device
Face detection, text recognition and the final flattening all execute in your browser through WebAssembly. Your image is never uploaded, never held on a server, and never seen by anyone but you. The tool works with the network disconnected, and there is nothing on our side to delete afterwards because nothing on our side ever existed.
For a redaction tool this is not a marketing point, it is the whole proposition. The images people need to redact are the images they least want to hand to a third party: identity documents, medical records, legal disclosures, screenshots containing customer data, photographs of children. Uploading such a file to a cloud service in order to obscure part of it inverts the goal — you have created an unredacted copy on someone else's infrastructure in order to produce a redacted one on yours.
It also means there is no account, no sign-up and no credit cost. Blur and redact is free and unlimited on every plan, because there is no server-side work to fund. The AI tools elsewhere on OpusImg — background removal, upscaling, restoration — do upload, and are labelled server-processed to make the distinction visible. This one does not, and that difference is worth knowing per tool rather than assuming either way.