How to Redact Customer Data in a Screenshot

Blurring is not redaction. What to remove, how to remove it so it cannot be recovered, and why the reliable answer is never to capture it in the first place.

Last updated August 2026

This guide gets you to the point where you can publish a screenshot taken from a real account without exposing anybody's data, and you will know why the blur tool in your screenshot app is not sufficient for it. The short version: cover, do not obscure - and better still, do not capture it.

Before you start

Work out what actually needs removing. It is more than names and email addresses. Account IDs and URLs containing them, invoice and order references, IP addresses, avatars and profile photos, company names on a B2B account, dates that combine with anything else to identify someone, and internal identifiers that map back to a customer in your own systems.

If your product is used by named companies, the company name alone is often identifying enough to matter contractually, even where it is not personal data.

The same line of text shown twice: once blurred, where the word shapes remain visible, and once covered by a solid opaque block.

Real blur, applied here at render time. The letterforms are still in the pixels.

Steps

Prefer a demo account over redaction.
Every step below is mitigation for a capture that should not have contained real data. Screenshotting a seeded demo account removes the entire problem and takes less time than careful redaction.
If you must redact, draw solid opaque shapes.
Filled rectangles in a flat colour, fully opaque, entirely covering the text including its descenders. Solid black or a flat brand colour both work.
Never use blur or pixelation on text.
Both are reversible in principle: they are transformations of the original pixels, not removals, and short predictable strings like emails and IDs are exactly the case where reversal is most feasible. Blur is a visual convention, not a security control.
Flatten the image before exporting.
If your editor keeps the redaction as a separate layer, exporting to a layered format ships the original underneath the black box. Export to flat PNG and reopen it to confirm.
Check the areas you were not looking at.
Browser tab titles, the URL bar, notification counts, autocomplete dropdowns, and anything reflected in a chart tooltip. The data you remembered to redact is rarely the data that leaks.
Strip the metadata.
Screenshots can carry the capturing device and, on some systems, location. Run the exported file through a metadata stripper before publishing.
Have somebody else look at it.
You know what you intended to redact, which makes you the worst person to check whether you did.

Common mistakes

Blurring rather than covering. The single most common error, and the one with actual consequences. Treat blur as decoration.

Redacting the visible instance and missing the repeat. The same email often appears in a header, a table row and a tooltip. Search the image systematically rather than scanning it.

Assuming a small font is unreadable. Readers zoom, and so do the people looking for exactly this.

Publishing the layered source file. PSD, Sketch and some PNG export paths preserve layers. Flatten, export, reopen, verify.

Redacting so heavily the image teaches nothing. A screenshot that is 60% black rectangles has lost the thing it was there to show. This is another argument for demo data - it needs no redaction and reads better.

When this stops scaling

Careful redaction is a per-image discipline, and disciplines fail at volume. Every screenshot is a fresh opportunity for somebody in a hurry to blur rather than cover, or to miss the tab title.

The exposure is also asymmetric in a way that most documentation risks are not. A stale button label costs a reader thirty seconds; a leaked customer email is a data incident, potentially a reportable one, and it stays in the page's history and in whatever has already cached it.

The scaling answer is not better redaction habits. It is to stop capturing real screens: a seeded demo account for manual capture, or images rendered from the product's interface code with fictional content, so there is never any real data present to remove. SupportPages generates documentation images that way, from your repository rather than from a live account. If your help centre currently contains screenshots taken from production, that is worth auditing this week regardless of what you do next.