Screen Sharing for Online Classes & Meetings · Browser-Only, No Plugin
Your full screen. A single window. One browser tab. Pick the scope, click Share, you're sharing. Built for the teacher who needs to show a slide deck, the tutor who needs to solve a math problem live, and the trainer who needs to demonstrate software — without asking IT to whitelist a Chrome extension.
Powered by the W3C getDisplayMedia
browser API. Same standard Google Meet uses. What we did differently: we kept it on the
free tier.
LiveLoop Screen Sharing, defined. Browser-native screen sharing for LiveLoop video meetings using the W3C getDisplayMedia API. Three sharing modes — entire screen, single application window, single browser tab — selected from the browser's native picker. System audio can be shared alongside the visual stream when the mode is tab or entire-screen (browser-level limitation prevents audio in window mode). Up to 1080p shared content resolution depending on host network; adaptive when bandwidth drops. Permission is host-only by default; granted to participants per-segment from the participant roster. No plugin, no extension, no app on any operating system. Included on every LiveLoop plan from the free tier upward.
Defining Artifact · Three sharing modes side-by-side
The same Share Screen click opens the browser's native picker. Three tabs in the picker correspond to three completely different privacy scopes. Pick the wrong one and your WhatsApp notifications pop up in a Class 10 PTM.
The teacher's rule of thumb: If it's a class with parents or students in the room, use Tab or Window. Entire Screen is for staff sessions where the audience is internal.
Why this matters
Screen sharing seems trivial until it isn't. Here are the four most common failures during a real online class — and how the modes-and-permissions design avoids each.
Mid-PTM, a WhatsApp notification pops up on the entire-screen share. Sometimes innocuous, often not. Window or Tab mode keeps notifications outside the chosen window invisible to the audience.
Half the screen-share solutions in the market still ask for a browser extension. School and college IT departments can't push extensions to managed devices. Native getDisplayMedia API removes that dependency entirely.
Some platforms allow any participant to share by default. A few minutes into the class, an accidental or deliberate takeover happens. Host-only share by default with per-segment grants stops this at the door — documented in detail on the moderation page.
Sharing a YouTube video for the class but forgetting to tick "Share Audio" in the browser picker. The students see the video, no sound. Tab or Entire Screen mode + the audio toggle gets sound through. (Window mode can't share audio — a browser limitation we name honestly rather than work around.)
Use cases by audience
What changes between audiences is which mode is the default choice — and what they share most.
CBSE, ICSE, State Board class teachers running Wednesday online days and term PTMs.
Teachers share PowerPoint slides for chapters, single PDF worksheets, occasional YouTube explainer videos. The teacher's laptop also has personal apps and notifications, so the safer modes are essential. The class teacher's WhatsApp does not belong in the science lesson.
Lecturers and IQAC officers presenting in classroom and accreditation contexts.
Lecturers share LMS browser tabs, NPTEL videos, research papers in PDF form, and occasionally code editors for CS courses. For NAAC peer-team interactions, the safer Window or Tab modes keep the institutional desktop private from external evaluators.
Tutors and subject teachers solving problems live on screen for coaching batches.
A NEET physics tutor needs to solve a problem live — write equations, draw a circuit diagram, walk through a derivation. Shares a digital writing app like Microsoft Whiteboard or Excalidraw in a single tab. The students see exactly the working, nothing else.
L&D managers and product trainers demonstrating SaaS, ERPs, or internal tools.
The trainer demonstrates Salesforce, SAP, Tally, or an internal admin panel. The session needs to show the full software UI, which often means jumping between windows. Entire Screen mode is necessary; the trainer pre-clears notifications before sharing.
Browser compatibility
Every modern browser supports screen sharing — but the supported modes and audio behaviour differ. Here is the honest matrix.
| Browser | Entire Screen | Window | Tab | Tab Audio |
|---|---|---|---|---|
| Chrome 72+ | ✓ Yes | ✓ Yes | ✓ Yes | ✓ Yes |
| Edge 79+ | ✓ Yes | ✓ Yes | ✓ Yes | ✓ Yes |
| Brave | ✓ Yes | ✓ Yes | ✓ Yes | ✓ Yes |
| Firefox 66+ | ✓ Yes | ✓ Yes | Limited | Not supported |
| Safari 13+ (macOS) | ✓ Yes | ✓ Yes | Limited | Not supported |
| Safari (iPhone / iPad) | Not supported | Not supported | Not supported | Not supported |
| Chrome on Android | Newer versions only | Not supported | Newer versions only | Limited |
The matrix reflects what the browser APIs support — not LiveLoop limitations. Full device coverage (which devices, which OS combinations) is documented at /liveloop/features/cross-platform/.
Open standards · No proprietary stack
Every modern browser has supported screen sharing since 2018 via the same W3C specification. The reason it's still hard to do well: the standard tells you how to capture, not how to keep a teacher's WhatsApp out of the lesson. That's the product work on top.
Part of the Media Capture and Streams specification. The browser-native function that returns a video stream of the screen, window, or tab the user picks. Supported in Chrome 72+ (Feb 2019), Firefox 66+, Safari 13+, Edge 79+.
The three-tab "Entire Screen / Window / Chrome Tab" dialog is rendered by the browser, not by LiveLoop. The user sees their familiar OS-level prompt, the same one Google Meet, Whereby, and Jitsi use.
When the user picks Tab or Entire Screen, the browser exposes a Share Audio checkbox. Window mode does not include the checkbox — this is a browser-level limitation across all WebRTC sites, not a LiveLoop one.
The Section 5 notice requirement covers personal data capture. The persistent sharing indicator visible to all participants throughout a screen-share session satisfies the notice requirement.
Screen-share permission is part of the host moderation control surface. By default host-only; granted to participants per-segment. Full moderation logic at /liveloop/features/moderation/.
The shared content stream uses the same adaptive bitrate logic as participant video — if bandwidth drops, frame rate and resolution adjust to keep the stream smooth. Detailed adaptive logic at /liveloop/features/hd-video-audio/.
I'm a one-man coaching center. I teach JEE physics to about a hundred and forty students across four batches from my home office in Coimbatore. Until last year I was running classes on a free platform that forced me to share my entire desktop — because the tab share didn't work properly on Linux. So every class, before starting, I would close every other app on my laptop. Fifteen minutes of prep for a one-hour class.
With LiveLoop's tab share, I open one Excalidraw tab, I share that one tab, and I teach. The students see the Excalidraw canvas, my equations, my circuit diagrams. They don't see my inbox. They don't see my WhatsApp. Most importantly, my pre-class setup time went from fifteen minutes to thirty seconds.
For a single-teacher operation those fifteen minutes per class multiplied across four batches a day is one extra batch per week. That's real money for someone like me.
In a LiveLoop meeting, when the host or a permitted participant clicks Share Screen, LiveLoop
calls the browser's navigator.mediaDevices.getDisplayMedia() function. The
browser opens its native picker — Chrome shows Chrome's, Safari shows Safari's, Firefox shows
Firefox's. The user picks a screen, window, or tab. The browser returns a video stream of
that selection to LiveLoop. LiveLoop sends that stream to the meeting's SFU server, which
distributes it to all participants.
The browser handles every device-level concern: picking the source, capturing the pixels, encoding the stream, showing the persistent "you're sharing your screen" indicator. None of that requires LiveLoop-specific code; the browser already has those capabilities through the W3C Media Capture standards.
When the host picks a Browser Tab or the Entire Screen, a Share Audio checkbox appears at the bottom of the browser picker. Tick it; the system audio from the tab or the entire device streams along with the visual.
Common use cases for tab/screen audio:
Window mode does not include the audio checkbox. This is a browser-level limitation in the current W3C specification — getDisplayMedia exposes window-level video capture but not window-level audio capture. The same limitation affects Google Meet, Zoom Web, and Jitsi. The workaround: if the audio matters, share the same content as a Tab instead.
Out of the box, only the host can share. This is the responsible default for online classes — the teacher controls the shared content; students do not take over the screen.
The host can grant screen-share permission to a specific participant in one click from the participant roster. Useful when:
Grants are reversible: revoke screen-share permission and the participant's share stops immediately. Full host moderation logic is documented at the moderation page.
This page owns one specific thing: the act of sharing your screen, window, or tab. Several adjacent questions get answered better elsewhere — or, in one case, honestly admitted not to be a LiveLoop feature today.
The mechanism is identical — all three use getDisplayMedia. The differences are about defaults and tier gating.
Real questions from principals, college lecturers, coaching tutors, and L&D managers evaluating LiveLoop's screen sharing.
No. Screen sharing uses the W3C getDisplayMedia API that every modern browser supports natively — Chrome 72+, Edge 79+, Safari 13+, Firefox 66+, Brave from launch. There is no plugin, no Chrome extension, no app to install. The school IT department does not need to whitelist or approve anything.
Three different scopes. Entire Screen shares everything visible on your monitor — including incoming notifications and other windows you switch to. Window shares only one specific application window, hiding the rest of your desktop. Tab shares only a single browser tab, hiding even the browser's other tabs. For sensitive teaching where personal email could pop up, Tab share is the safest choice.
Yes. When you pick Tab or Entire Screen in the browser picker, a Share Audio checkbox appears at the bottom. Tick it to stream system audio along with the visual — necessary when playing a YouTube video for a class, demonstrating software with sound, or sharing a recorded lecture. Window-share mode does not support audio because of a browser-level limitation, not a LiveLoop one.
By default, only the host can share. Out of the box, screen-share permission is locked to host-only — students cannot take over the screen during a class. The host can grant a specific student permission in one click from the participant roster (useful for a student presentation) and revoke it when finished. Full host moderation controls at /liveloop/features/moderation/.
Up to 1080p Full HD depending on the host's network bandwidth and the participant's screen size. The platform adapts to network conditions in real time — if bandwidth drops, the shared content's frame rate or resolution lowers automatically to keep the stream smooth. The same adaptive logic is documented at /liveloop/features/hd-video-audio/ for the video stream.
Phones and tablets can view a shared screen (and pinch-to-zoom to read small text), but sharing your screen from a mobile device is limited by browser support. iOS Safari does not allow tab sharing from mobile; Android Chrome supports it on newer versions. The recommended workflow is teachers sharing from a laptop or desktop, while students join and view from any device.
Only if you share Entire Screen mode. Notification popups, taskbar alerts, and other apps you switch to are all visible to participants. If you want to prevent this, share a single Window or a single Tab — those modes hide everything outside the chosen window or tab. For online classes with parents or students, Tab or Window share is strongly recommended.
Not as a built-in feature today. The honest answer: teachers who need a whiteboard typically share a browser tab with an external whiteboard tool (Microsoft Whiteboard, Jamboard, Excalidraw) which works perfectly via Tab share. We do not pretend to ship a feature we have not shipped — when a real LiveLoop whiteboard is on the homepage feature set, it will get its own documentation page.
Whatever was being shared at that moment is what the recording captures. If the host switches from active-speaker view to shared-content view, the recording follows the switch. Full recording layout details — including the Shared-Content-with-Speaker layout that keeps the speaker visible in a small overlay — at /liveloop/features/recording/.
Screen sharing is included on every LiveLoop plan including the free tier. It is treated as a baseline online-teaching capability, not a premium feature — there is no plan where you can hold meetings but cannot share your screen. Plan details at /liveloop/pricing/.
Book a 30-minute demo. We'll show you the three sharing modes side-by-side on a teacher's actual workflow — slides, YouTube video, online whiteboard tool.
From ₹0 / free tier includes screen sharing · No plugin · Browser-native · Built in Chennai
