How to blur sensitive data in a product demo (and why blur isn't enough)

A product demo often includes data you should not publish. Your account may contain customer names, colleague email addresses, revenue figures, and internal identifiers that are visible while you record.

Plan for sensitive data before you share the demo. A few minutes of review can prevent an otherwise useful recording from becoming a privacy incident.

What may be visible in your screenshots

Run through this list against the last recording you made. Most people find at least three.

• Customer and colleague names. Account lists, assignee avatars, comment threads, the “shared with” row.
• Email addresses. In profile menus, in autocomplete dropdowns that appeared while you typed, in the account switcher.
• Revenue and usage figures. Dashboards are the most-recorded screen in any product and the most likely to contain numbers you do not publish.
• Account and record IDs. Often visible in the URL bar, which you are also recording.
• Internal URL structure. admin., staging., /internal/ — a subdomain map you are handing to anyone who looks.
• Your browser chrome. Open tab titles say a lot: which competitor you were researching, which vendor’s invoice you were paying, the name of the deal in your CRM.
• Notifications. A Slack toast that arrives mid-capture will be in the frame forever.

The last two catch experienced people out, because you are concentrating on the app and the sensitive thing is outside it.

Blur, redact, or don’t capture

These are three different tools for three different jobs, and using the wrong one is the common mistake.

Blur softens a region while keeping its shape and colour. Use it when you want the screen to look real but the detail not to read — a customer list where the point is that there is a list, a dashboard where the shape of the chart matters and the numbers do not.

Redaction replaces a region with an opaque block, usually with a label. Use it for anything that must not be recovered: keys, tokens, account numbers, real names, anything covered by a contract or a regulation.

Not capturing it means using a demo account seeded with fake data instead of your production account. This is the right answer more often than people admit. It is faster than redacting fifteen steps well, it survives mistakes, and it means the next person to update the demo does not have to redo your careful work from memory.

The rule we would use: if it would be bad for exactly one person to see it, blur is fine. If it would be bad for anyone to see it, redact. If it would be bad and you are recording more than a couple of screens, use a demo account.

Why blur is not a security control

This matters and it is not widely understood.

Blur is a reversible mathematical operation. A Gaussian blur averages neighbouring pixels; it does not destroy information so much as spread it out. With a known blur radius and a small set of possible inputs, the original can often be reconstructed — and short, structured text is exactly the small set of possible inputs that makes this practical. Six-digit numbers, short names, and dates have all been recovered from blurred screenshots. The same applies to pixelation and to swirl or mosaic effects.

The practical version of this rule:

• Long, high-entropy strings — an API key, a UUID — are hard to recover but not worth the risk. Redact.
• Short, structured values — a PIN, a postcode, an order number, a first name — are the easy case for recovery. Always redact.
• Visual noise — dense text that should not distract from the button or chart — is a good use for blur.

Two more failure modes worth knowing:

Layered files leak. If you draw a black rectangle in a tool that preserves layers and export to PDF or SVG, the content underneath is still in the file. Anyone can move the rectangle. Flatten the image, or export to PNG, and check the result rather than trusting the editor.

Redaction has to happen before the file leaves your machine. Once you have uploaded the unredacted capture somewhere, redacting the copy does not un-upload the original. Whichever tool you use, check whether it stores the raw capture before you edit it.

A checklist before you publish

1. Full-screen the app before recording, or at least close every tab you would not screenshot deliberately.
2. Turn off notifications. Focus mode on macOS, Do Not Disturb on Windows. This is thirty seconds and prevents the failure you cannot fix without re-recording.
3. Log in as a demo user if one exists.
4. Check the URL bar on every step. It is the most commonly missed field because it is not part of the app.
5. Redact first, blur second. Do the must-not-be-recovered items while you are still being careful.
6. Look at every step at full size afterwards. Thumbnails hide text. This is where you find the email address in step 9.
7. Check the edges of the frame — sidebars, footers, the account menu that was open in one step and not the others.

What this costs, depending on your tool

Here is how the major tools in this category handle these controls.

Redaction and blur are paid features in three of the six major tools in this space:

• Scribe — redaction requires Pro, at $35/month ($25 annual)
• Arcade — blur is in the premium set, requiring Growth at $50/month ($42.50 annual)
• Guidde — “blur sensitive information” requires Pro; automatic PII redaction is Enterprise-only

In practice, a free tier may let you record your product but require an upgrade before you can publish a recording that includes a customer’s name. Privacy controls are part of the publishing workflow, not an optional enhancement.

Supademo includes blur and annotation in its editor rather than as a plan feature, which makes its free tier more suitable for testing customer-facing walkthroughs.

In Demonstratio, blur and redact are planned as core editor tools alongside hotspots and notes. We are still pre-launch and exact prices are not available yet, but the planned free tier includes the controls needed to make a recording safe to share.

There is also a smaller thing our capture does automatically: fields whose name or label matches password, token, secret, auth, payment, card, or otp are stripped from captured form metadata before anything is stored. That does not replace reviewing your screenshots, but it reduces the chance of storing common sensitive form values.

Related

• How to create a step-by-step guide with screenshots — the full method, redaction included
• What interactive demo software really costs in 2026 — including which features are gated where
• Demonstratio vs Arcade — how privacy controls are packaged