Hide what shouldn’t be shared
Screenshots are one of the most common ways sensitive information leaks: an email address in the corner, an auth token in a URL bar, a customer name in a table. This redactor lets you drag over those areas and bake the redaction directly into the image before you post it anywhere.
How it works
The original image is drawn onto a hidden backing canvas at its native resolution. When you drag a rectangle, the selected region is processed and written back into the backing canvas — the change is permanent, not a visual overlay:
- Black box fills the region with solid opaque black.
- Pixelate / blur divides the region into square blocks, averages the colour of each block, and repaints every pixel in that block with the average. Because the source pixels are overwritten, the detail cannot be recovered.
The on-screen canvas is a scaled copy for comfortable editing, but the export always comes from the full-resolution backing canvas, so quality is preserved.
Why “baked in” matters
Many people redact screenshots using tools that simply draw a layer on top — a rectangle in a presentation app, a sticker in a messaging app, or a CSS overlay. These are not real redactions: the original pixel data still exists beneath the layer, and anyone with the raw file can remove the overlay to reveal what was hidden. This happens regularly in public disclosure incidents where redaction was done incorrectly.
The backing-canvas approach here is different. The source pixels are permanently overwritten; there is nothing beneath the black box or pixelated region to recover. The test for a real redaction is whether the sensitive region survives being opened in any image editor and the layer removed — properly baked redactions do, CSS overlays and presentation-app shapes do not.
When to use black box vs pixelate
Black box is the right choice for the highest-sensitivity items: passwords, API keys, session tokens, personal identification numbers, account numbers, and medical information. It leaves no residual signal about the underlying content — not even rough shape or colour information.
Pixelate is appropriate when you want to hide the precise content while preserving context — for example, obscuring a person’s face in a screenshot while keeping the surrounding UI visible, or hiding a name in a table while keeping the table structure readable. The pixelated region retains approximate colour blocks, which can give useful context for documentation or bug reports.
Avoid light pixelation on small monospace text (code, tokens, addresses). The mosaic blocks can in some cases be partially read if the block size is small relative to the character height. When in doubt, use black box.
Common workflows
- Bug reports. Redact customer names, email addresses, or error messages containing PII before posting to public issue trackers.
- Documentation. Hide credentials or company-internal values in screenshots for public tutorials.
- Social sharing. Cover personal information visible in phone screenshots before sharing on social media.
- Support tickets. Remove authentication tokens from URL bar screenshots before submitting to third-party support.
Tips and notes
- Prefer a black box for the highest-sensitivity items like passwords, API keys, and account numbers — it removes all residual signal.
- Use a larger block size when pixelating small text; light mosaics over tiny fonts can occasionally be partially reconstructed.
- Undo rebuilds the image from a pristine copy and re-applies all but the last redaction, so it is always exact.
- Everything is local — safe for screenshots containing confidential or personal data.