Browser screen sharing lets you show selected on-screen content to someone through a web meeting or support session. The presenter chooses a source—such as a browser tab, application window, or display—and the service sends its changing visual content to the viewers.
It can avoid installing a desktop client, but the presenter still needs a supported browser and device, permission to capture the screen, and the appropriate meeting role. Viewing a shared screen and presenting one are different requirements.
How browser screen sharing works
There are two separate jobs: capturing the selected content and sending it to the session. MDN’s Screen Capture API guide describes how the browser produces a live stream of the source the user chooses. A meeting service can then use that stream for communication; saving a recording is another feature.
WebRTC is commonly used for real-time browser communication. A connection is not necessarily a direct route between two participants: the WebRTC connection guide describes network discovery and relay services used to establish connections. The service’s architecture and meeting configuration matter.
For the person sharing, the practical flow is simpler:
- Join the intended meeting or support session.
- Select its screen-sharing control.
- Choose the source offered by the browser.
- Confirm the selection.
- Check with a viewer that the right content is visible.
- Stop sharing when the task ends.
Choose a tab, window, or entire screen
| Source | Useful for | Check before sharing |
|---|---|---|
| Browser tab | A web application, document, or browser video | The selected tab is correct and any necessary audio is included. |
| Application window | A demonstration within one program | Required dialogs and the relevant content appear in the shared view. |
| Entire display | A task that moves across several applications | Unrelated content and notifications are hidden; the correct monitor is selected. |
Use the narrowest source that covers the task. A tab or window can reduce unrelated exposure, but information inside that source is still visible. Check the preview and the viewer’s actual view rather than assuming a selected mode makes every other detail private.
If the meeting itself appears inside the captured source, the repeated view can create a distracting mirror effect. Select the application or tab you want to demonstrate instead.
Test a screen share before an important session
A useful screen-share test checks the viewer’s result, not just the presenter’s sharing indicator. Use an approved test session with representative content and another participant who can confirm what arrives.
- Open the document or application you will show.
- Join with the intended browser and device.
- Select the source and start sharing.
- Ask the viewer to name the visible page or window.
- Scroll or perform a representative action; check that the change appears.
- Ask whether important text is readable.
- If sound matters, play a short sample and ask the viewer to confirm it.
- Stop sharing and confirm that the demonstration has ended.
Repeat the test when you change the device, browser, sharing mode, or required sound source. For a task that crosses applications, test the transition rather than only the first screen.
Screen-share test Service and meeting: Presenter browser / device / OS: Viewer browser / device: Selected source: tab / window / display Correct content confirmed: Changes visible: Important text readable: Microphone speech audible: Tab / application sound needed and confirmed: Source transitions checked: Sharing stopped: Problem observed and next check:
Understand screen audio and microphone audio
Speaking into a microphone and sharing sound from a tab or application are separate tasks. A meeting can transmit your speech while the viewer hears none of the video you are demonstrating.
MDN notes that audio support varies with the browser and capture source, and a requested screen stream may contain video without audio. Use the service’s documented audio option and test it with the source you will present. For saved capture, the internal-audio recording guide explains the same source distinction.
When speech is missing, check the selected microphone, mute state, and application permissions through the microphone setup guide. When application sound is missing, changing the microphone alone may not solve the problem.
Check support for presenting, not only joining
A meeting service can support joining on a device while limiting its ability to present. Check the documented browser, operating system, and mobile requirements for the feature you need. Use current instructions instead of inferring capability from browser market share.
Meeting hosts and administrators may also restrict presenting. On a managed computer, operating-system permissions and organization settings can affect capture. Ask for the approved configuration when the sharing control is unavailable.
The table summarizes documented presenter checks for common services. Plans and web-client features change, so confirm the details for the account and invitation you actually use.
| Service | Browser route | Presenter check |
|---|---|---|
| Screendesk | Browser room started from a helpdesk ticket, with host and guest links | Workspace live-call access and the customer’s supported device |
| Zoom Web App | Meeting access without downloads or plugins | Host sharing restrictions; mobile browsers can view a share but cannot start one |
| Google Meet | Present now, then a tab, window, or entire screen | Host and administrator restrictions; the pre-join Present route enters Companion mode, where microphone and speaker are unavailable |
| Teams for web | Share in the meeting controls | Chrome or the latest Edge; Linux is not currently supported for screen sharing; on a Mac, the browser needs screen permission |
| Whereby | Browser rooms and embedded meetings | Source choices depend on the browser; mobile-device screen sharing is excluded |
| Jitsi Meet | The public meet.jit.si service or an organization’s own deployment | The room creator needs an account on meet.jit.si; features depend on the deployment |
| GoTo Meeting | Web version at app.goto.com | Which meeting experience the organizer hosts and what its web client supports |
| Webex web app | Join from this browser | Meeting platform, guest access, presenter role, and browser requirements |
For example, a customer on a phone may be able to watch your demonstration but unable to show their own phone screen through that browser. If the customer’s screen is the evidence you need, resolve the presenter requirement before scheduling.
The browser screen-sharing options guide compares documented routes in Screendesk, Google Meet, Zoom, and Teams, including the distinction between general web support and presentation requirements.
Sharing, recording, remote control, and co-browsing
| Action | What it does | What to verify |
|---|---|---|
| Screen sharing | Shows selected visual content during a session | Source, viewers, and stop-sharing control |
| Recording | Saves supported content for later review | Required agreement, recording status, capture scope, and storage |
| Remote control | Lets another participant operate a device through a supported feature | Separate access, capability, and the approved purpose |
| Co-browsing | Provides a product-specific shared website interaction | Supported pages, data handling, and interaction controls |
Do not assume that starting a screen share automatically saves a replay or grants another person keyboard and mouse control. Check those features separately. If you need a saved call, follow a documented recording route.
What browser permissions do—and do not—establish
For the standard screen-capture API, the browser asks the user to choose a source. MDN’s getDisplayMedia reference explains that permission is requested for each capture and cannot be permanently reused. Capture also requires a secure context and a user interaction such as a button click.
That source selection controls what is captured. It does not establish the meeting audience, whether another participant records the content, how the provider processes a session, or whether a saved file is appropriately shared.
Likewise, encryption during transport and end-to-end encryption are different claims. For example, Zoom’s encryption documentation distinguishes its default transport encryption from an enabled end-to-end mode. Check your provider’s documentation and the actual session configuration rather than assuming that “browser” or “WebRTC” guarantees a particular protection.
Use a clear support workflow
For a customer session, agree on the problem before sharing. Ask the customer to demonstrate it, note the observed result, and make one focused test at a time. Keep the distinction between what you saw and what you think caused it.
Name who presents so neither person waits for the other to start; a customer demonstrating an error is a different task from an agent explaining a solution. A bare meeting link can leave a first-time participant unsure what to do, so state the purpose, expected device, and presenter in the invitation:
Let's look at [specific task] together. Join here: [meeting or guest link] Please use [supported device/browser] and open [application/page]. [You / I] will share the relevant screen after we join. You will choose what to show through the sharing controls. We will stop sharing once [task or check] is complete. If the link or sharing does not work, we can use [fallback].
Do not promise that every browser or phone will work, and remember that “no desktop installation” does not mean “no screen-access prompt.” During the session, give one action at a time, name visible labels rather than saying “over there,” and let the participant make the selection on their own device:
- “Please choose the tab with the export page, then confirm Share.”
- “I can see the page title and the blue Export button. Is that the page you intended to show?”
- “Please select Export once. We will wait for the message before doing anything else.”
- “You can stop sharing now; I no longer need to see that page.”
A shared screen is a visual view; it does not give assistive technology access to the underlying controls or document. The W3C accessible-presentation checklist notes that content sent through screen sharing often is not accessible, so provide the relevant document or written steps directly when needed, narrate each action and result, and use available captions.
When the task ends, stop sharing and ask the viewer to confirm the screen is gone. Ending a demonstration, stopping a recording, and leaving a meeting are different controls. After the session, write the outcome and next action in the case. Use an issue reporting template for a handoff or the troubleshooting worksheet for tests that need to be continued.
Screendesk’s browser support calls are one route for that workflow: the agent starts Live Screen Sharing from the helpdesk sidebar and receives a host link, while the customer joins through a guest link without installing an app or creating an account. If you do not need to investigate together, a requested screen recording can let the customer demonstrate the issue asynchronously. Review the support-call guide when you also need a replay tied to the investigation.
Troubleshooting checklist
- No sharing control: check presenter role, host restrictions, and supported browser/device.
- Source selection fails: check capture permissions and the service’s documented requirements.
- Wrong source: stop and select again, then ask the viewer to confirm.
- Unreadable content: enlarge the relevant text and reduce the shared area when practical.
- Frozen or delayed view: inspect the connections and unnecessary workload on both devices.
- Missing sound: distinguish microphone input from tab/system sound and test the correct source.
- The session cannot proceed: switch to the agreed screenshot, document, or written-steps fallback.
Frequently asked questions
Can I share my screen directly in a browser?
Yes, through a service and presenter setup that support it. You still need the session access, the appropriate role, and capture permission.
Can a viewer see my other tabs?
That depends on the selected source and service behavior. A single-tab share is narrower than sharing a browser window or entire display. Inspect the source and confirm what the viewer sees.
Does browser sharing mean no installation for everyone?
It can, when the service supports the organizer, presenter, and viewer tasks on their browsers. Confirm those tasks separately, especially for mobile devices or advanced features.
Which browser screen-sharing option is free?
Check the current plan or deployment conditions against your required session length, participants, and features. Free access does not necessarily include recording, unlimited duration, or the support workflow you need.
Does browser sharing require the fastest internet plan?
Check the service’s requirements and test the task. Connection stability, upload capacity, content motion, and device workload affect the result; a universal speed target does not describe every session.
Is a screen share the same as a screenshot?
No. A screenshot is a saved moment. A live screen share shows changes over time. Choose the format that supplies the necessary context.
