Most remote teams review video the same way: someone shares their screen on the call and everyone watches their window. It works, and for a five-minute clip nobody should change anything.
It starts costing you on the longer ones — a conference talk, a two-hour training module, a recorded customer interview, a design walkthrough. That is where synced playback is a different proposition, and where a couple of things are worth knowing before you point it at internal video.
What screen sharing costs on a long recording
| Screen sharing on a call | Synced playback | |
|---|---|---|
| What people see | a re-encoded copy of one window | the original file, each in their own browser |
| Quality | commonly capped around 720p and 30fps | original on every side |
| Who carries it | the presenter's upload and CPU | nobody — only small position messages |
| Text in the video | often unreadable after compression | as sharp as the source |
| Someone joins late | they see the current frame | they are placed at the room's position |
| Who can control it | the presenter | anyone in the room |
The row that decides it for most teams is the fourth one. Recordings of screens — a code walkthrough, a dashboard, a slide with a table on it — are exactly the content that video compression handles worst. Sharing a screen of a screen recording compresses it twice, and small text is the first thing to go.
The last row matters more than it looks too: when anyone can pause, you get "wait, go back ten seconds" without asking someone else to do it for you.
When it's worth it
- Onboarding material. New starters watching the same module together, pausing to ask things, instead of everyone watching alone and nobody asking anything.
- A conference talk or recorded training the team wants to go through and discuss.
- A customer interview or user session recording, where "the bit at 14:20" needs to mean the same moment for everyone in the room.
- A design or code walkthrough someone recorded rather than presented live.
And the ordinary case: everyone is remote, the recording is long, and you want it to feel like watching it in the same room rather than narrating it to each other.
The one thing to check first: what reaches our server
Before pointing this at internal video, be clear on what travels. This is the part most tools gloss over, so here it is plainly.
The video never passes through our server. Everyone plays the original themselves, in their own browser, with their own access. What crosses the wire is small JSON: position and play state once a second, a play/pause/seek command when someone acts, and chat text.
But the host's page URL does travel. Whoever opens the room shares the page address and title with the room, so the panel can offer "Open the video" — and that address is written to the server's application log. Room membership and chat are not stored, and nobody else's page is ever read. But if your internal URLs themselves are sensitive — a link that encodes a customer name, an unreleased project codename — that is the detail to weigh, and you should weigh it before rather than after.
The practical version: for a recording on a platform your whole team already uses, this is a non-issue. For something where the address alone gives away more than the video does, use the call's screen share instead and accept the quality cost.
The full breakdown of what is stored and what isn't is on the privacy page, written section by section against the code.
Setting it up
- Everyone installs the extension — download here. Chrome 116 or newer; Edge, Brave and Opera are expected to work but are unverified. Firefox and Safari are not supported.
- Everyone signs in to whatever hosts the video. This is the requirement that decides whether this works for you: each person needs their own access. If the recording sits behind a company login, everyone needs an account that can open it — the extension doesn't grant access it doesn't have.
- One person opens the recording and creates a room, then shares the 8-character code.
- Everyone presses the purple sync button. All sides count down from three and start together.
- Keep your usual call running alongside for the talking. We don't do voice chat, and the two don't interfere.
What it handles for you
- Corporate and course players usually work, including players nested inside shadow DOM — which a lot of internal video platforms use. There is no list of supported services; the extension hooks whatever
<video>element is on the page. - Buffering is waited out. If one person stalls for more than 700 milliseconds, everyone pauses and you continue together. On a shaky home connection that is the difference between a review and a series of apologies.
- Ads are waited out on YouTube, JW Player and Video.js — relevant if the recording is an unlisted YouTube video, which plenty are.
- Chat survives fullscreen, so a comment doesn't need the call. Messages are never stored on our server.
The limits worth knowing
Rooms hold up to 5 people. This is a small-team tool, not a webinar tool: everyone's buffering and pauses affect the whole room, which is what makes it good for five people reviewing something and wrong for fifty watching a broadcast.
Everyone needs their own access to the video, as above. If only one person can open it, screen sharing is your option — what that costs is here.
Only the host sets the page. Playback control is shared — anyone can pause or seek — but the room's page belongs to whoever opened it.
An account is needed; opening a room and joining one are both free, with no card asked. How it works · All the questions, answered plainly