How to Hide Sensitive Data in Screen Recordings

One accidental exposure of customer data in a product demo can trigger a GDPR incident, destroy trust, or leak API keys. Yet most teams treat data hiding as an afterthought — blurring in post and hoping they caught everything. Here's a systematic approach.

Prevention beats correction: the demo account

The single best investment: a dedicated demo account with realistic but entirely fictional data.

A good demo account has:

Realistic names: "Acme Corp," "Jordan Rivera," "Northstar Agency" — not "Test User 1" or "asdf"
Believable metrics: Revenue of $47,200/mo (not $0 or $999,999,999)
Populated state: 15-30 items in lists, some with activity, some without. Empty states and overloaded states both look wrong.
Consistent narrative: All data should tell a coherent story. If there's a user named "Jordan," their activity should make sense for one person.

Set this up once and maintain it. Every recording starts from this known-safe state.

Pre-recording checklist

Even with a demo account, check these before recording:

☐ Browser bookmarks bar hidden (may contain internal URLs)
☐ URL bar doesn't show internal domains (.internal, staging.*, admin.*)
☐ No notifications visible (may show real customer names)
☐ Dock/taskbar cleared of internal tools
☐ Browser extensions hidden (especially password managers)
☐ Desktop files not visible
☐ No real email addresses in any visible field
☐ API keys or tokens not in URL parameters or visible developer tools

When you can't use a demo account

Sometimes you need to show a real environment — for support videos, internal demos, or when the demo account doesn't have the right feature configuration. In these cases:

CSS overlay technique: Use DevTools to add CSS that replaces sensitive text content:

[data-testid="customer-name"] {
  font-size: 0;
}
[data-testid="customer-name"]::after {
  content: "Acme Corp";
  font-size: 14px;
}

This replaces visible text without modifying actual data. Add a custom stylesheet with all replacements before recording.

Browser extension approach: Some extensions let you define text replacement rules that apply visually. This is faster than CSS but less precise.

Post-production hiding

If sensitive data slipped through, fix it in post:

Static blur: Apply a Gaussian blur (radius 15-25px) over the sensitive area. Ensure the blur region is slightly larger than the text — tight blurs reveal character shapes through the blur.

Color block: Overlay a solid rectangle matching the background color. More secure than blur (zero information leakage) but looks more obviously redacted.

Tracking: If the sensitive data moves (scrolling, animation), your blur must track it frame-by-frame. Most video editors support motion tracking for this purpose.

Important: Do not use the pixelate/mosaic effect at low settings. Research has shown that pixelated text can be reconstructed if the mosaic blocks are small enough. Always use Gaussian blur or solid overlays.

Common mistakes

Blurring the email but not the avatar: Profile pictures can identify people
Hiding the name but not the URL: /users/john-doe-12345 reveals identity
Missing data in notifications: Toast messages and browser notifications often contain customer names
Forgetting the browser tab title: Page titles often include customer or organization names
Console output visible: DevTools console logs may contain tokens, user IDs, or PII

The nuclear option: generated animations

For public-facing marketing content where data exposure risk must be zero, consider not recording real product instances at all. Generated product animations work from UI descriptions rather than live data — every piece of text is intentionally placed, eliminating the possibility of accidental exposure entirely.