How to redact a screenshot so it stays redacted

Redacting a screenshot feels like a solved problem. Draw something over the sensitive part, export, send. In practice it is one of the more reliable ways to leak data, and the failures are systematic rather than careless.

This is a practical guide. It applies whatever tool you use.

Rule 1: the pixels must actually be gone

The classic failure is a black rectangle drawn over content in a format that keeps the content underneath. It is famous in PDFs, where a filled shape placed above a text layer hides nothing at all — the text is still selectable, and copying it out takes one keystroke.

Images are not immune. Any editor that preserves layers, and any export format that carries them, can preserve what you thought you covered. The safe operation is to flatten: produce a new image in which the redacted region is genuinely different pixels, with no record of the originals anywhere in the file.

A useful habit: after redacting, reopen the exported file as if you had just received it, and try to get the information back out.

Rule 2: pixelation is not encryption

Pixelation — averaging blocks of pixels — looks destructive and often is not. Because it is a deterministic transformation of the original, an attacker who knows the font, the approximate text size and the block grid can render candidate strings, pixelate them the same way, and compare. When the space of possible values is small, the search is cheap.

Published research has demonstrated recovery of pixelated text under exactly these conditions, and the constraints are not exotic — a screenshot of a web app has a known font, a known size and a known background. Short, predictable values are the most vulnerable: account numbers, short IDs, names, addresses drawn from a known list.

Blur has the same shape of problem. A small Gaussian radius over 12px text removes far less information than it appears to.

Rule 3: match the method to the stakes

This is the practical core of it.

• Solid bar or fill. The only method that removes the information rather than transforming it. Use it for anything that actually matters: credentials, tokens, account numbers, real customer identifiers, anything under a contractual or regulatory obligation.
• Heavy blur or coarse pixelation. Acceptable when you are hiding the shape of something rather than its content — showing that a sidebar has a list of customers without showing who they are — and when the underlying values would not be catastrophic if recovered. Use a radius that visibly destroys the glyph structure, not one that leaves ghost letterforms.
• Cropping. Underrated. If the sensitive column is on the right of the table, the safest redaction is to not capture the right of the table.

Rule 4: redact everything, not the obvious thing

The email column gets redacted because it is obviously an email column. What survives is everything that was not visually obvious at 6pm:

• the same address repeated in a tooltip, a page title or a browser tab
• an autocomplete dropdown left open behind the region you cropped to
• a notification banner that arrived while you were framing the shot
• an internal hostname or a session ID in the URL bar
• the name of an unreleased project in a tab, a bookmark bar or a Slack sidebar

The discipline that helps most is to read the screenshot once, deliberately, as a stranger — before you annotate it, not after.

Rule 5: keep the original if you can, and know where it went

Redaction is destructive by design, so you want the unredacted original if the bug report needs revisiting — but you want it somewhere you control, not in the same folder you drag files out of. Equally: if your capture tool uploads screenshots to a server as part of its sharing flow, the unredacted version may have been uploaded before you redacted anything. Worth knowing which of your tools do that.

Why this shaped a feature

Flint Capture will find the text regions in a capture and obscure all of them in one action, with blur, pixelate or a solid bar. Two things about that are deliberate.

First, it is all of them. The mistake is almost never the row you looked at; it is the row you did not. Automatic detection is not a substitute for reading the image, but it removes the failure mode where nine of ten rows got covered.

Second, the solid bar is a first-class option rather than an afterthought, because for the cases that genuinely matter it is the only correct one. Marks stay editable while you work and are flattened on export, so what leaves the app is pixels, not a layer stack.

It runs on device, with Vision. The image is not uploaded anywhere to be scanned, which would be a strange thing to do to a picture you are redacting because it is sensitive.

If a redaction would be a serious problem to get wrong, use a solid fill, flatten it, and reopen the export to check. Everything else is a matter of taste.