Every help article, support reply, and bug report is a chance to leak something: a customer's email in a table, an API key in a settings page, an internal admin URL in the address bar. Most leaks aren't dramatic. They're a screenshot someone took in a hurry and pasted into a public doc.
This guide covers what to redact, which redaction methods actually hold up, and a checklist to run before any screenshot leaves your team. The free screenshot annotator handles everyday redaction in your browser, and we'll be clear about where you need something stronger.
What to redact in a screenshot
Scan the whole image, not just the part you're pointing at. Sensitive data hides in sidebars, headers, tooltips, and browser chrome.
- Personal data: customer and teammate names, email addresses, phone numbers, street addresses, avatars, and profile photos.
- Credentials and secrets: API keys, access tokens, webhook secrets, passwords, session IDs, and one-time codes.
- Financial details: card numbers (even partial), bank details, invoice amounts tied to a named customer.
- Internal infrastructure: admin URLs, staging hostnames, internal IP addresses, database or bucket names, and account or tenant IDs in the address bar.
- Business context: other customers' logos in a workspace switcher, deal sizes, unreleased feature names, private Slack or email previews in notifications.
- Browser chrome: bookmarks bar, other tab titles, extension icons, and the signed-in profile name.
Blur vs. pixelate vs. solid block: what actually hides data
Not all redaction is equal. The difference is whether the method destroys the information or just scrambles it.
| Method | What it does | How safe it is |
|---|---|---|
| Light blur | Smooths pixels together but keeps the overall shapes of letters. | Weakest. Short words and numbers can often be guessed or matched. |
| Pixelation (mosaic) | Replaces areas with averaged color blocks. | Hides text from a casual reader, but researchers have reversed pixelated text with public tools under the right conditions. |
| Solid opaque block | Replaces the pixels with one flat color. | Strong, as long as it's flattened into the exported image and not a removable layer. |
| Crop or recapture | The data is never in the image at all. | Strongest. Nothing to recover. |
Why pixelation and blur can be reversed
Pixelation averages each block of pixels into one color. That sounds destructive, but each block's color still depends on the letters underneath. If an attacker knows the font and size (easy, since the rest of the screenshot shows them), they can render candidate text, pixelate it the same way, and compare the result.
This isn't theoretical. Depix is an open-source proof of concept for recovering plaintext from pixelized screenshots. Its documentation notes it needs a linear box filter, a known font, and an image without additional compression, so it doesn't work on everything. Bishop Fox researcher Dan Petro later released Unredacter and wrote that when you redact text you should “use black bars covering the whole text,” and never pixelation, blurring, or swirling.
The other trap: editors that keep the original
How you save matters as much as how you hide. In 2023, researchers disclosed CVE-2023-21036, nicknamed “aCropalypse”: Google Pixel's Markup tool wrote edited screenshots without truncating the original file, so much of the original image could be recovered from cropped or marked-up versions. Google patched it in its March 2023 update.
The same lesson applies to documents. Bishop Fox's write-up warns that black bars must be applied to the image itself, because coloring text black in a document can leave it recoverable. A black rectangle drawn over a PDF or slide may still have selectable text underneath.
How to redact a screenshot, step by step
- Prevent it first. Capture from a demo workspace with fake names, example.com emails, and placeholder keys. This removes most redaction work.
- Hide the browser chrome. Use a clean browser profile or crop out the address bar, tabs, and bookmarks.
- Crop aggressively. If a sensitive column isn't needed for the step, crop it out instead of covering it.
- Redact what remains. In the screenshot annotator, choose Black out for anything sensitive (or Pixelate for incidental details) and drag over the area. Cover the whole field, not just the characters, so length and shape aren't revealed.
- Escalate for secrets. If the area contains a password, key, token, or card number, use Black out at minimum, and prefer recapturing with fake values.
- Export a new file. Download a fresh PNG and share that, never the original capture or an editable project file.
- Verify the export. Open the exported file on its own, zoom in, and confirm nothing readable remains.
A note on how our free tool works: Black out draws a solid opaque bar and Pixelate samples coarse blocks from the original image. Both are flattened into the exported PNG, so the original pixels aren't kept in the file. It runs in your browser and nothing is uploaded. Pixelate is still pixelation, which is why step 5 exists.
Where sensitive data hides in common screenshots
Some screens are almost always risky. Know them, and slow down when you capture one.
| Screen | What leaks | Better approach |
|---|---|---|
| API keys or developer settings | Keys, webhook secrets, signing secrets | Recapture with a placeholder key in a demo account; never pixelate a live key |
| Customer or user tables | Names, emails, plan details, usage | Seed a demo workspace with fake rows, or crop to the column you're explaining |
| Billing pages | Card digits, invoice amounts, billing addresses | Use a test account; crop to the control you're pointing at |
| Browser dev tools and network tabs | Cookies, auth headers, tokens in URLs | Avoid sharing these externally; if you must, recapture after logging out of real sessions |
| Shared inbox or ticket views | Customer messages, email previews, assignee names | Use a sample ticket and hide the ticket list |
Partially masked is not redacted
Many apps show secrets as something like sk_live_••••••••4f2a. That's better than the full key, but it still reveals the key type, the environment (live versus test), and the last characters, which can help someone confirm a guess or identify the account. In public docs, show a clearly fake value like sk_test_EXAMPLE instead.
The same goes for emails. j•••@acme.com still tells readers which company is your customer. Swap in example.com addresses, which are reserved for documentation use, and nobody has to guess what's real.
Screenshot redaction checklist
Run this before a screenshot goes into a help center, ticket reply, changelog, or sales deck:
- Captured from a demo account, or every real name, email, and ID is covered.
- No API keys, tokens, passwords, or card numbers anywhere, including partially masked ones.
- Address bar, tab titles, bookmarks, and notifications are cropped or clean.
- No internal hostnames, staging URLs, or tenant IDs visible.
- Redactions cover whole fields, not just the characters.
- The file you're sharing is a newly exported, flattened image.
- Any secret that was ever visible in a shared image has been rotated.
For annotation style beyond redaction (arrows, numbered markers, color rules), see how to annotate screenshots.
Redaction at scale in documentation
Redacting one screenshot is quick. Redacting every step of a 20-step guide, and doing it again after each product update, is where mistakes creep in. The most reliable fix is upstream: record guides in a dedicated demo workspace so there's nothing sensitive to capture in the first place.
Steperly turns one recording into a step-by-step guide with a screenshot per step, plus a walkthrough video and an interactive demo. Recording in a clean demo account means every output starts clean, and steps stay editable if you need to adjust an image before publishing to your branded help center. See how teams use it for customer onboarding guides and support documentation.
- Depix: recovering plaintext from pixelized screenshots (proof of concept)
- Bishop Fox, “Never Use Text Pixelation To Redact Sensitive Information” (Feb 2022)
- SecurityWeek, “Google Pixel Vulnerability Allows the Recovery of Cropped Screenshots” (CVE-2023-21036)
- RFC 2606, Reserved Top Level DNS Names (example.com reserved for examples)