Hide sensitive information in screen recordings: passwords, keys, personal data

Secrets get into recordings in boring ways: an autofill dropdown, a terminal history, a notification, a customer's email in the corner of an admin page. A little setup stops most of them, a two minute review catches the rest, and a fixed order of steps contains the one that slips through.

By the VeoRec team · Oct 3, 2026 · 12 min read

Nobody decides to put a production API key in a bug report video. It happens because the terminal still showed yesterday's output, or a password manager popped a dropdown of every saved login, or a Slack notification slid in with a customer's name in it. Most leaks get there by accident like this, so the way to hide sensitive information in screen recordings is less about clever redaction afterwards and more about a few habits before and during recording.

The habits are cheap. A browser profile set up once, a tab instead of the whole screen, a pause before you log in, a fast review before you paste the link. The one expensive mistake is treating blur as a fix for a leaked password, and the last part of this piece covers what to do instead.

Know where secrets hide on a normal screen

Passwords on a login form are the obvious case, and the easiest to avoid. The leaks that actually happen are usually somewhere less obvious:

Notice that most rows are about the edges: the address bar, the sidebar, the corner where notifications appear, the dropdown under a field. You are concentrating on the middle of the screen, which is exactly why the edges get missed.

Record the smallest area that does the job

The single most effective habit is choosing what to capture. Chrome's share dialog offers three choices, and they differ a lot in how much they expose:

• A Chrome tab captures only the page in that tab. Other tabs, other apps, desktop notifications, your taskbar and your second monitor are not in the recording. For anything that happens in a web app, this is the safest choice.
• A window captures one application window: no desktop, no other apps, but everything inside that window, including any other browser tab you switch to while recording.
• The entire screen captures everything, including pop-ups, notifications and whatever you switch to by accident.

Default to a tab, and step up only when you must show something outside the browser, such as a terminal or a desktop app. Browser-based recorders use this same dialog, so the same three choices apply; our guide to recording on Chrome explains what each one captures in more detail.

Set the stage before you press record

If you record your screen regularly (bug reports, demos, support replies), ten minutes of one-off setup removes most of the risk for good.

Use a separate browser profile for recording

Create a Chrome profile just for recordings. Sign it in to test or demo accounts only, keep the bookmarks bar hidden or empty, and do not save real passwords in it. When you record in that profile, there is nothing personal in the autofill, the history suggestions or the bookmarks to leak. It also means the address bar suggests demo URLs, not your bank.

Record with test data, not real customers

Wherever you can, demonstrate on a staging environment or a demo account seeded with fake but realistic data: "Ada Example, [email protected]". Real customer names and emails in a training video are a privacy problem every time someone watches it, for as long as it exists. Data protection law points the same way: the GDPR's data minimisation principle asks that personal data be limited to what is necessary for the purpose. A recording that explains how refunds work does not need a real customer in it.

When you must show a real record (a support case, a production bug that only happens for one account), open only that record, scroll so other customers are off screen, and plan to blur what remains.

Clean up the terminal and the editor

Clear the terminal before recording so old output is gone, and scroll the editor away from .env files and config with credentials. Avoid commands that print secrets, like dumping every environment variable with env or printenv. Refer to them by name instead, and if you need to prove a variable is set, print its length (echo ${#API_KEY} in bash) rather than its value. If you record terminals and editors often, our guide to recording your IDE and terminal covers this in more depth.

Look behind you, too

If the camera is on, the room is part of the recording. A whiteboard with a roadmap, a sticky note with a Wi-Fi password, a letter on the shelf, a second monitor showing your inbox: all of it is in frame. Background blur hides most of that, but check the unblurred view once before external recordings. Our guide to camera on or off covers when the camera is worth it in the first place.

Silence notifications on every device in view

Notifications are a frequent surprise in screen recordings because they arrive on their own schedule. A message preview can contain anything: a customer complaint, a salary discussion, a password someone pasted into chat.

If you record a single tab, operating system notifications are outside the capture. For window and full screen recordings, turn them off:

• On a Mac, System Settings has a Notifications option for whether notifications are allowed when mirroring or sharing the display, documented in Apple's notification settings guide. Check it is set to off, and turn on Do Not Disturb as well for good measure.
• On Windows, Do Not Disturb turns on automatically in some situations, such as when duplicating your display, but Microsoft's list of automatic rules does not include recording your screen. Turn it on yourself from the notification center before you start.
• In chat and email apps, pause notifications or set yourself to do not disturb, since some show their own in-app banners inside the window you are recording.
• On your phone, if it is anywhere near the camera, turn it face down.

Our general screen recording tips cover the rest of a clean setup: zoom level, cursor, closing tabs.

Pause before sensitive steps, and mark surprises

Sometimes the sensitive step is part of the flow you are showing: logging in, opening an account page, confirming a payment. Do not try to be quick about it on camera. Pause the recording, do the sensitive part, check the screen is clean, and resume. The viewer sees a jump from the login page to the dashboard, which is fine; nobody needs to watch you type a password.

Typing on camera leaks more than people think. Password fields hide characters, but they show how many there are, and if your camera shows your hands on the keyboard, a patient viewer can follow the keys. Two-factor codes, recovery codes and card numbers are worse. Pause for all of them.

When something sensitive appears that you did not plan for, do not stop and restart in a panic. Drop a marker at that moment so you can find it later; if your recorder has chapter markers (a single key press in many tools), "somewhere in minute three" becomes a marked point. Then cut or blur that section before sharing.

Review the recording before you paste the link

Modern recorders are built for speed: in VeoRec the video uploads while you record, and the share link is already copied when you stop. That is great for a quick update and risky for a recording that went near anything sensitive, because the link exists before you have checked what is in it.

So make the review a habit: before pasting the link anywhere, watch the recording at double speed and look specifically at the edges. Address bar, tab titles, sidebars, corners, dropdowns. Pause on every page change and every form. It takes a minute for a two minute video, and it is the step that catches the leak you did not notice while talking.

What a 2x review can turn up

Take a three minute recording made for a colleague, showing how a refund is processed in an admin tool. Recorded as the entire screen, in a normal browser profile, on a production account. A review at double speed might find:

Notice that none of these is the thing the video is about. Every one sits at an edge or appears for a second or two. Recording a single tab in a clean profile with demo data would have prevented all five.

Check the title, thumbnail and summary too

The video is not the only thing people see. Recorders increasingly generate text and images around it, and those can carry the same secret. VeoRec gives every recording an automatic title, and on Pro an AI summary, and generated text like this can repeat what you said. If you talked about "the Acme account migration" or read out a customer's name, the title or summary may repeat it, and titles show up in link previews, inboxes and search. Read them before you share, and rename the video if needed.

Thumbnails deserve the same glance. A shared link often unfurls with a frame from the video, and email add-ons that insert a video as a clickable thumbnail put that frame in the message itself. If that frame shows a customer list, the preview leaks it to everyone who sees the message, whether or not they press play. If your recorder lets you set a custom thumbnail, choose a harmless frame, such as the title screen or an empty dashboard.

Run through this list before and after recording. It keeps your ticks in this browser, so it is there next time.

Blur personal data, but cut and rotate credentials

Blurring is the tool most people reach for, and for a lot of incidental information it is the right one: a customer's email at the top of a support ticket, a colleague's name in a sidebar, an order number. Draw a box over it, apply the blur, and the casual viewer sees nothing. Try it on the settings page below, which shows both kinds of secret: a customer email, where a blur is enough, and a live API key, where it is only the first step.

Two caveats. First, a blur box only protects people who watch after it has been applied. In VeoRec, blur boxes take effect when you render the edit, so anyone who opened the link before that saw the original. Blur before you share, not after someone points it out.

Second, blur and pixelation are not secure redaction for text. Security researchers at Bishop Fox released a tool called Unredacter that recovered pixelated text by generating candidate text, pixelating it the same way and comparing. Their advice for text that must stay secret is blunt: "use black bars covering the whole text. Never use anything else." A video, where the same text can appear across many frames at slightly different positions, is likely to give an attacker more to work with, not less.

So split the decision by what the information does:

The rule for credentials is simple: if a working password or key was on screen in a recording that left your machine, assume it is compromised and replace it. Cutting the clip is housekeeping; rotating the key is the actual fix. Our guide to editing screen recordings shows how to cut a section and apply blur boxes.

If a secret already went out, rotate first

Say you shared a bug report video an hour ago and just noticed a live API key in the terminal at 1:12. The order of operations matters.

1. Revoke or rotate the credential Do this first, before touching the video. GitHub's guidance on remediating a leaked secret makes the same point for code: removing the secret is not enough; revoking it with the provider is the step that matters.
2. Restrict the recording Stop further viewing while you fix it: remove the link from where you posted it, or restrict who can open it.
3. Cut the section and re-share Edit out the exposed part, check the transcript, and share the cleaned version.
4. Check where else it went Was it downloaded, embedded in a doc, forwarded, posted in a public channel? Each copy is outside your edit.
5. Tell whoever owns the system Security teams would rather hear about a rotated key from you than find it later. Note what was exposed and for how long.

Viewer analytics help with the last two steps if your tool has them. Data that shows how far each viewer got tells you whether anyone reached 1:12 before you pulled the link, though for a credential the safe answer is still to rotate it.

Control who can open the link

Most share links work for anyone who has them, without an account. That is what makes them convenient: a client or a developer at another company can watch without signing up. It also means a link pasted into the wrong channel, forwarded by email or posted in a public issue tracker can be opened by people you never intended.

For routine recordings, the defence is simply care about where you paste links: a private channel rather than a public one, the ticket rather than the open issue. For recordings that show anything confidential even after cleanup, such as a client's unreleased product, add a gate. VeoRec Pro can put a password on a link or ask viewers for an email address before they watch; plan details are on the pricing page. Teams that record customer data as part of support work should agree on these rules once, in writing; the support screen recorder page shows how that workflow looks.

Remember that access control only covers the copy you host. A downloaded file or an embedded video on another site follows that site's rules. If a recording must stay confidential, do not offer it as a download.

What to do before your next recording

Spend ten minutes once: create a recording profile in Chrome, sign it in to demo accounts, seed or find some fake data, and set up a quick way to turn notifications off. That one setup removes most of the risk from every recording after it.

Then keep three habits per recording. Record a tab unless you have a reason not to. Pause for logins and anything you would not want to read aloud. Watch the video at double speed before you paste the link. And if a working credential ever does appear in a recording that left your machine, rotate it first and tidy the video second. For bug reports specifically, our guide to video bug reports covers what to show in the first ten seconds, with privacy in mind.