How to record a single browser tab with audio

Why record a single tab rather than the screen

A tab recording contains only that tab. Notifications, your other monitors, your menu bar, your bookmarks, and everything else on the desktop are excluded automatically, without any editing.

For a demonstration that stays inside one web page, this is often the most focused choice. It excludes other applications and displays from the captured surface. File size and processor use still depend on the selected tab, its dimensions, motion, and the browser encoder.

It is also the most privacy-preserving option available. If you are recording something for a customer or a public audience from a machine that also has your email open, sharing a tab removes an entire category of risk rather than relying on you to remember to close things.

On macOS, tab audio in a current Chromium browser is generally more predictable than whole-system audio. The share picker still decides whether audio is offered, so confirm it with a short test.

Recording a tab, step by step

Open what you want to record in its own tab, set your sources in Screencast, press record, and choose the Chrome Tab or Browser Tab section of the share picker rather than Entire Screen.

Set everything before you press record. Screencast locks its controls the moment recording begins, so the mode, microphone, system-audio toggle, frame, background, and camera layout all need to be right beforehand.

When the share picker appears, look for the tab section — Chrome and Edge separate entire screens, windows, and tabs into distinct groups. Select the tab you want, tick the tab-audio checkbox if the page makes sound you need, and share.

Screencast will confirm what you selected with a notice naming the browser tab. If it does not say that, you shared something else, and it is worth stopping immediately rather than discovering it later.

Use the start delay if you need a moment to switch to the tab and get the cursor into position. Three or five seconds is usually enough to avoid opening the video on the Screencast interface.

Capturing the tab's audio

Turn on System audio in Screencast before you record, then include tab audio in the browser's share dialog when that option is offered. Screencast can record only the audio track the browser returns.

The Screencast toggle requests shared audio. The browser controls the picker and may show a checkbox or another audio control. If the selected stream has no audio track, Screencast cannot add one afterwards.

Tab audio and microphone narration can both be on. Screencast mixes them into a single track before recording, which keeps the file simple but means the balance you set beforehand is the balance you keep. If you plan to talk over a video, lower the video first.

When the browser supplies tab audio, it is intended to cover the selected tab rather than unrelated applications or system alerts. Browser and operating-system behavior should still be verified before an important recording.

Confirm it worked before you record anything long. Record fifteen seconds, open the review panel, enable preview audio, and listen. The live preview is muted during recording by design, so silence while capturing tells you nothing.

What a tab recording cannot do

It cannot follow you. Switching to another tab, another window, or another application leaves the recording showing the tab you selected — not what you moved to.

The surface is fixed when you share and cannot be widened afterwards. If the workflow you are demonstrating crosses from a web app into a terminal, a desktop application, or a second browser window, you need to record an entire screen instead.

This includes things that feel like part of the same page. A file-picker dialog, a native print preview, an operating-system permission prompt, and a browser extension popup are all outside the tab and will not appear.

A page that opens a new tab mid-demonstration will lose you too. If your flow includes an external sign-in, a payment provider, or anything that opens a second tab, record the screen.

Decide which of these applies before you start. There is no way to convert a tab recording into a screen recording after the fact, and a long take discovered to be missing the important half is the most expensive mistake available here.

Framing a tab recording for where it is going

Leave the frame on Original for documentation and tickets. Use 16:9 for anything that will be embedded or presented, and 9:16 or 4:5 for a social or mobile destination.

Original captures the tab at its natural dimensions with no cropping or padding, and it is also the cheapest option because Screencast can pass the capture through without composing each frame. For a bug report or a walkthrough attached to a ticket, that is all you need.

A fixed frame letterboxes the capture into the shape you chose rather than cropping content out, so nothing is lost — but a wide browser tab placed into a 9:16 frame ends up small. If a vertical output is the goal, narrow the browser window before recording so the content fits the shape.

Backgrounds and padding sit behind the composed frame and give a tab recording a deliberate look for a presentation or a landing page. They also turn on the compositor, so leave them off when you want the lightest possible recording.

Make the content bigger before you record rather than expecting viewers to zoom. Increasing the page zoom to 125 percent or raising the font size in the application costs nothing and is the difference between a readable recording and an unusable one on a laptop screen.

Preparing the tab itself

Use a clean profile or a fresh window: no unrelated bookmarks, no signed-in personal accounts, no autofill about to suggest something you did not intend to show.

The tab recording captures the page, and on most browsers the bookmarks bar and tab strip of that window as well. A bookmarks bar is a surprisingly effective way to leak what you are working on.

Autofill and browser password suggestions appear over the page and are captured with it. If your demonstration involves typing into a form, check what your browser will offer before you record it.

Sign in as a test user rather than as yourself where the application allows it. Real names, real email addresses, and real customer data in a recording that gets shared onward is the most common cause of a recording having to be redone.

Close the developer tools unless they are the point. They take up frame space and shrink the content everyone actually came to look at.