How to Prepare Your Browser for a Live Product Demo

By TabStage · Published August 12, 2026

Fine for daily use isn't the same as demo-ready

Most of the time, your browser's state doesn't matter to anyone but you: a dozen open tabs, a bookmarks bar full of internal links, a window sized however it happened to land. None of that gets in your way day to day. The moment you share your screen with a prospect, every one of those things becomes something someone else is looking at — and unlike your own daily use, you don't get to ignore it.

This isn't about demo methodology — narrative, discovery questions, objection handling. It's specifically about the environment itself: the browser you're about to put in front of an audience, and whether it's actually ready for that, right now.

Illustrative example: the same live tab, shown as an ordinary shared browser window versus the same content presented inside a TabStage scene.

What changed between the two: the browser chrome and bookmarks bar are gone, the content is framed and scaled instead of floating in a raw window, and there's nothing on screen the audience doesn't need to see. Everything below this point is about the preparation work — what to close, hide, and check — before you ever reach for framing like this.

What's open: choosing what you share

The first decision is scope: do you share one tab, one window, or your entire display? This is the single biggest lever you have over exposure, and it's worth deciding on purpose rather than accepting whatever your meeting tool suggests by default.

A tab usually offers the narrowest presentation scope — only that page's content is visible, so switching to another app or getting a notification elsewhere doesn't leak into the share. A window gives more flexibility if your demo genuinely spans a few tabs, but it also exposes more of the browser's own UI. An entire display gives you maximum freedom to switch between applications, at the cost of the largest exposure surface. Exact behavior — what a viewer sees during an app switch, whether notifications render into the share — varies by operating system and meeting platform, so if a specific behavior matters for your setup, check it once in the tool you actually use rather than assuming it matches every platform.

Failure mode: sharing "the whole screen" out of habit because it's one click, then getting a Slack notification or an alt-tab caught live. What good looks like: deciding tab, window, or display before the call, based on what the actual demo requires — not what's fastest to click.

What's visible: closing the gap between "open" and "showing"

Takeaway: close what doesn't belong in the call instead of just hiding it, and silence notifications at the operating-system level, not only inside the app you're demoing.

Even inside the tab or window you've chosen to share, plenty is visible that has nothing to do with your product: a bookmarks bar, a row of extension icons, unrelated tabs sitting next to the one you're presenting, and any notification that happens to fire while you're live.

Close what doesn't belong in the call rather than just hiding it — a minimized window or a collapsed bookmarks bar is one accidental click away from reappearing. And load the correct tab, logged in and ready, before the call starts — working that out live adds dead air and risk to a moment that should feel rehearsed.

Notifications

Silence notifications at the operating system level, not just inside whichever app you're demoing — muting a chat app inside itself doesn't stop the OS from popping up a banner over it. Calendar reminders, chat messages, and OS-level alerts are all common sources of an unplanned interruption mid-demo, and all worth checking before you go live rather than reacting to one on camera.

A separate demo profile

If you demo often, keeping a separate browser profile just for that purpose turns most of the above into a default instead of a checklist. It isn't mandatory — everything here is achievable in your everyday browser with a few minutes of cleanup — but a dedicated profile means a clean, quiet window is what you start from, rather than something you have to remember to build every time.

Failure mode: a password manager icon, an internal company extension, or a personal bookmark folder visible in the toolbar the entire call, signaling "this is someone's everyday browser" instead of a prepared presentation. What good looks like: a browser state that has nothing in it beyond what the demo actually needs.

What's readable: sized for your viewer, not for you

Takeaway: set zoom and framing for what a remote viewer will see after compression, not what's comfortable on your own monitor up close.

Text and UI elements that are perfectly readable on your own monitor, sitting close to it, are not guaranteed to stay readable once a meeting platform compresses and rescales the shared window on someone else's screen. This is the dimension most demo advice skips — it's treated as a given, and it usually isn't.

Set your browser's zoom, and your product's own UI density if it has one, for what a remote viewer will see — not what's comfortable six inches from your face. Frame the content deliberately instead of sharing a maximized window with a small interface floating in a sea of blank space. If you're about to click something specific, make sure the cursor is easy to follow; a default-sized pointer against a busy interface is easy to lose in exactly the moments you most need attention on it.

Failure mode: a demo that looks fine on your own screen and turns into a squint-and-guess exercise once it's been compressed for a remote viewer. What good looks like: checking your setup at roughly the resolution and window size your viewer will actually experience, not your own.

What's safe: what could go visible that shouldn't

Takeaway: check both what's around the demo (other open tabs, apps, and windows) and what's inside it (the actual data the product displays), and confirm your login/session state before you go live rather than mid-call.

Protecting sensitive data

Safety is about what's around the demo and what's inside it. Around it: other open tabs, apps, or windows with anything you wouldn't want seen, closed or hidden before you start — not discovered mid-alt-tab. Inside it: real customer names, real financial figures, or another customer's account, all worth checking for even in a screen you've shown a dozen times before. Demo or test data is the simplest way to make this a non-issue where it's practical.

Login and session state

Login and session state deserves its own check: an expired session forces you to log in live, in front of the audience — at best a delay, at worst a moment where the wrong account's data is one misclick away. And watch for permission prompts (camera, microphone, notifications) that can surface mid-demo if a browser or site decides that's the moment to ask.

Failure mode: a screen-share picker that briefly shows fifteen open windows, one of which had a customer's real data on it. What good looks like: nothing visible during the demo that you wouldn't be comfortable with the audience seeing, checked before you go live rather than discovered during it.

What happens if something breaks

Takeaway: decide your fallback for the riskiest step, and know how to reload or reconnect, before the call — not while it's happening.

Every demo has one step most likely to go wrong — a live integration, a flaky network call, a feature still being polished. Decide what you'll do if that specific step fails before you're standing in front of someone when it does, not in the moment itself. That might mean a second tab pre-loaded to a known-good state, a fallback screen, or simply a rehearsed line that keeps the call moving while you recover.

The same applies to the mechanics of the call itself: know what a dropped connection or a crashed tab looks like from your side, and have a quick way to reload or reconnect without losing the thread of what you were showing.

Failure mode: a single point of failure with no plan, so any hiccup derails the entire call. What good looks like: a specific, rehearsed answer to "what do I do if this exact thing breaks," for the one thing most likely to.

Browser preparation, the presentation layer, and the meeting platform

Everything above is achievable with no tool at all — closing tabs, silencing notifications, checking zoom, using a separate profile. That's deliberately how this guide is written: browser preparation is something you do, not something a tool does for you. It's useful to see it as one layer in a three-layer model, because a live demo actually passes through all three on its way to an audience.

Browser preparation is the layer covered by this guide: you control the tabs and windows that are open, notifications at the OS and app level, which accounts you're signed into, what data is visible, whether your login/session state is current, and the general state of the browser environment itself. Nothing in this layer is automatic — it's manual preparation, every time.

The presentation layer controls how the tab you've already chosen actually appears once you share it: its framing, crop, scale, background, an optional browser or device frame, webcam placement and styling, and whether that setup can be saved and reused. This is the layer TabStage operates in. TabStage is a Chrome extension that captures the one tab you choose and displays that tab, live, inside a framed presentation scene — crop, scale, padding, a rounded corner radius, a shadow, an optional browser or device frame, and an optional webcam bubble with its own placement and nameplate. That scene is the window you actually share. TabStage does not perform the browser-preparation work above: it doesn't close your tabs, silence your notifications, hide anything inside Google Chrome, or secure a login for you.

The meeting platform — Zoom, Google Meet, Microsoft Teams, or whatever you use — is the layer that actually transmits the resulting presentation to your audience. TabStage does not replace this layer either; it changes what's inside the window you hand off to your meeting platform, not how that window reaches the other side of the call.

For a repeat presenter, TabStage's saved scenes — a complete setup you can save, reload, and hand to a teammate as a .tabstage.json file — are one concrete way to make the presentation layer specifically repeatable, though writing down your settings works too.

Putting it together

The specifics above compress into a short sequence worth running through before any live demo:

1. Narrow what you plan to share — tab, window, or entire display.
2. Remove unrelated browser and app state: extra tabs, bookmarks, extensions, notifications.
3. Check readability at roughly the size and resolution your viewer will see.
4. Verify accounts, visible data, and login/session state.
5. Load the exact demo path you'll actually click through, ready to go.
6. Decide your fallback for the step most likely to break.
7. Only then, control how the live product is presented.

For the full 25-point readiness check across all five dimensions — including the browser-preparation work this guide covers in depth — see the 25-point Live Product Demo Checklist. And for the visual side of presenting once your browser is ready, see how to make screen sharing look professional.

FAQ

Do I need a separate Chrome profile to demo safely?

No. A separate profile is a convenience for people who demo often, not a requirement. Everything in this guide is achievable in your everyday browser with a few minutes of preparation.

Is sharing a single tab always the safest option?

It's usually the narrowest presentation scope, since it excludes the rest of your browser and desktop by default. Exact behavior varies by operating system and meeting platform, so if a specific detail matters for your setup, verify it in the tool you actually use.

Does TabStage prepare my browser for me?

No. TabStage controls how the tab you've already chosen and cleaned up gets presented — framing, background, scale, webcam. It doesn't close tabs, silence notifications, or secure your data; that preparation is still yours to do, and this guide is about exactly that.

More from TabStage

• 25-point Live Product Demo Checklist — the scoreable version of readiness across Focus, Presence, Clarity, Safety, and Repeatability.
• How to make screen sharing look professional — once your browser is prepared, how to make presenting it look intentional.