The Complete Guide to Browser-to-Browser Video Calls

You click a link, and suddenly you are face to face

Someone sends you a link. You tap it. Your browser asks, once, if it can use your camera and microphone. You say yes, and there they are: a friend, a colleague, a doctor, a job interviewer, live on your screen. No app to download. No account to create. No "join with meeting ID and passcode." Just a link and a tab.

It feels almost too simple, and that simplicity hides something genuinely clever. In a normal video call, your face does not travel directly to the other person. It travels to a company's servers first, gets processed, and is relayed back out. A browser-to-browser call can skip that middleman entirely: the video goes straight from your device to theirs, encrypted, with no server in the middle ever seeing it.

This guide is about how that works and why it matters. It starts with the everyday experience, the link and the tab, and works its way down to the networking protocols, the cryptography, and the topology math that make a serverless call possible. Read as far as you need. The top is for using it; the bottom is for understanding it.

If you want to try one right now, TabTasker's video call runs entirely in your browser, needs no account, and connects you directly to the people you invite. The rest of this article explains what is happening behind that link.

The everyday version: what is a browser-to-browser video call?

The plain-language version has three parts.

First, it runs in the browser. There is nothing to install. The camera, the microphone, the video window, the screen sharing, all of it is delivered by the web page itself, using capabilities modern browsers already have built in. You are one click away from a call on any reasonably recent phone or laptop.

Second, it is direct. This is the part that makes it different from the household names. Your audio and video travel on a connection that goes straight from your device to the other person's device, peer to peer, rather than being uploaded to a company's data centre and streamed back down. We will spend most of this article on how that is even possible.

Third, it needs no account. You do not sign up, you do not log in, you do not hand over an email address. You create a room, you share the link, people join. When everyone leaves, the room is gone. There is no recording sitting on a server somewhere, because there is no server in the middle holding the call.

Here is how the direct, browser model compares to the conventional cloud approach.

The pattern: a direct browser call wins decisively on privacy and friction for small conversations, and loses to cloud platforms only when you need to broadcast to a large audience. For the calls most of us actually have, one to a handful of people, direct is both simpler and more private.

Who uses this, and when

A therapist or doctor holding a remote consultation has an obvious reason to care that the video is not flowing through, or being recorded on, a third party's servers. A direct, encrypted call keeps a sensitive conversation between exactly the two people having it.

A job candidate and interviewer can meet without either party installing corporate software or creating an account on a platform they will never use again.

A family spread across countries can talk face to face by sending a link in a chat, with no "which app does grandma have" negotiation.

A small remote team can jump on a quick call, share a screen to look at a bug together, even open a shared scratch-doc, without spinning up the heavyweight meeting platform for a five-minute chat.

What unites them is small scale and a preference for privacy and zero friction over enterprise webinar features. That is exactly the sweet spot of the browser-to-browser model.

How it works, part one: the browser already has the pieces

For most of the web's history, a web page could not touch your camera. Real-time video meant a plugin (remember Flash?) or a native app. That changed with a browser technology called WebRTC (Web Real-Time Communication), now built into every major browser. WebRTC is the engine under every browser-based call, and it provides three things.

The first is media capture. A single browser API, getUserMedia, asks your permission and then hands the page a live stream from your camera and microphone. (A sibling API, getDisplayMedia, does the same for screen sharing, which is why screen share "just works" in a good browser call, and why sharing screen audio is possible too.)

The second is the peer connection: RTCPeerConnection, the object that represents a direct link to one other person. You attach your media stream to it, and it handles the brutally hard work of encoding the video efficiently, adapting quality to the network, recovering from lost packets, and decoding the incoming stream, all in real time.

The third is data channels: an arbitrary, low-latency, peer-to-peer pipe for any data, not just audio and video. This is the quiet hero of the platform. It is what lets a call carry a text chat, a shared document, file transfers, even a game of chess between two participants, all over the same direct connection as the video.

So the browser already has the camera, the connection, and the data pipe. What it does not know, at the start, is how to find the other person and how to reach them across the internet. That is the genuinely hard part.

How it works, part two: introductions (signaling)

Two browsers that want to talk have never met. Each one knows a lot about itself, what video codecs it supports, what its network addresses are, what encryption keys it will use, but nothing about the other. Before any video can flow, they have to exchange this information. That exchange is called signaling.

The dialogue follows a fixed script called the offer/answer model, expressed in a format called SDP (Session Description Protocol):

1. The first browser generates an offer, a document describing "here is what I can do: these codecs, this resolution, these encryption parameters."
2. That offer has to reach the second browser somehow. This is the only step that needs a helper in the middle: a small signaling server whose entire job is to pass these introduction messages back and forth.
3. The second browser reads the offer and generates an answer: "great, here is what I can do, let us settle on this common subset."
4. The answer travels back through the signaling server to the first browser.

And that is it for the signaling server's involvement. Here is the crucial point that people miss: the signaling server only carries the introductions, never the call itself. Once the two browsers have exchanged offer and answer, they open a direct connection and the signaling server drops out of the conversation entirely. It never sees a single frame of video. It is a matchmaker, not a chaperone. (A well-designed one is also purely reactive, it only relays a message when a browser sends one, and never originates traffic of its own.)

How it works, part three: finding a path (ICE, STUN, and the NAT problem)

There is a wrinkle. The offer and answer describe who each browser is, but the browsers still have to find a network path to each other, and the modern internet makes that surprisingly hard.

The culprit is NAT (Network Address Translation). Almost no device has a unique, publicly reachable address anymore. Your laptop sits behind your home router, which sits behind your ISP, each layer translating addresses. Your laptop's idea of its own address ("192.168.1.42") is meaningless to anyone outside your house. So how does a browser tell a stranger "connect to me" when it does not even know its own public address?

The answer is a protocol called ICE (Interactive Connectivity Establishment), and its helper, STUN (Session Traversal Utilities for NAT). A STUN server does one tiny, beautiful thing: a browser asks it "from where you are sitting on the public internet, what does my address look like?" and the STUN server replies "you appear to be coming from this public address and port." Armed with that, each browser gathers a list of every way it might be reachable, its local address, its public address as seen through NAT, and offers all of them as ICE candidates. The two browsers then systematically try every combination of their candidate addresses until one pair connects. That winning path becomes the call.

There is a heavier fallback that some systems use, called TURN, where a relay server forwards the actual media when no direct path can be found. But a TURN relay, by definition, sits in the middle of your call and handles your video, which is exactly the middleman a privacy-first design is trying to eliminate. So a privacy-first browser call stays STUN-only: it uses STUN to help two browsers find each other, and if a direct path genuinely cannot be established, it fixes that at the connectivity layer rather than by routing your video through a relay. The principle is firm: help the peers find each other, never carry their conversation.

How it works, part four: why small groups (the mesh)

A two-person call is one direct connection. What about a group?

The simplest way to do a group call without a central server is a full mesh: every participant opens a direct connection to every other participant. In a four-person call, each person holds three connections; everyone is sending their video straight to everyone else.

This is elegant and private, no server ever touches the media, but it has a hard ceiling, and the ceiling is pure arithmetic. The number of connections in a full mesh of n people is n * (n - 1) / 2, which grows with the square of the group size. More punishing still is the upload demand on each person: in a mesh, you must send your own video stream separately to every other participant. With seven other people on the call, your device is uploading seven copies of your camera feed at once. Home internet upload speeds give out long before the math does.

This is precisely why browser-to-browser group calls cap at a small number, around eight participants is a sensible hard limit, while cloud platforms can host thousands. The cloud platforms cheat, in the honest sense: they put a powerful server (an SFU, a Selective Forwarding Unit) in the middle that receives one copy of your video and fans it out to everyone else, so your device only ever uploads once. That server is what makes huge calls possible, and it is also the very middleman a peer-to-peer design refuses to use. The tradeoff is fundamental: you can have a serverless, private call, or a massive one, but the same architecture cannot give you both. For the small calls most people actually have, the private option is the better deal.

Is it actually private? The encryption

Direct routing would mean little if the stream were readable in transit. It is not. WebRTC mandates encryption: media is protected with DTLS-SRTP, and the encryption keys are negotiated directly between the two browsers during the handshake. Because the keys are established peer to peer and the media never passes through an intermediary, a properly built browser-to-browser call is end-to-end encrypted by construction. There is no point at which an unencrypted copy of the video exists on someone else's machine, because it never reaches someone else's machine at all.

Room access can be hardened further with a password. A nice trick used by privacy-first tools is to put the access secret in the part of the URL after the # (the fragment). By a long-standing rule of the web, the fragment is never sent to the server, it stays in the browser. So a link like .../call#k=secret carries a key that the signaling server literally never receives; only the browsers that open the link can use it. The secret to your room is shared through the server's plumbing without ever being visible to it.

The upshot, in one line: the people on the call can see and hear each other, and essentially no one else can, including whoever runs the signaling.

Beyond video: the data channel surprises

Because WebRTC's data channel can carry anything, a good browser call is often more than a call. Over that same direct, encrypted connection you can find:

• Screen sharing, including the audio from the shared tab, for walking through a design or debugging together.
• A shared text chat that lives only in the call and disappears with it.
• A collaborative scratch document that participants edit together in real time, the same kind of shared-state technology that powers an online whiteboard.
• Even a game, a quick match of chess between two participants while waiting for a third to join, has been built on nothing more than the data channel and a bit of shared-state logic.

None of these need a server. They are all just bytes flowing through the same direct pipe the video uses.

Scheduling a call without a calendar server

One last neat trick. Scheduling usually implies a backend: a calendar database, accounts, notifications. A privacy-first browser tool can schedule a meeting with no backend at all, by leaning on two open standards the rest of the world already supports. It generates an .ics file (the universal calendar format that Google Calendar, Outlook, and Apple Calendar all understand) describing the meeting and its join link, and it can pre-fill an email invite via a plain mailto link. The user's own calendar and email client do the remembering. There is no meeting stored on the tool's servers, because the tool does not have meeting-storing servers. The standards do the work.

Frequently asked questions

Do I need to install anything or make an account? No. A browser-to-browser call runs in any modern browser, and a privacy-first one needs no account. You create a room and share the link.

Is a browser video call secure? WebRTC requires encryption, and in a direct peer-to-peer call the media never reaches a third party, so it is end-to-end encrypted by construction. Add a room password (ideally one carried in the URL fragment, which never reaches the server) for access control.

How many people can join? In a serverless mesh, a small group, around eight is a sensible ceiling, because each participant uploads their video to every other participant and home connections cannot sustain more. For large webinars you need a server-based platform.

Does it work on phones? Yes. WebRTC is supported by mobile browsers, so a link opens a call on a phone just as it does on a laptop.

Why is the video sometimes lower quality than a cloud app? In a mesh call your device does all the encoding and uploading itself, with no server to help. The browser adapts quality to your connection. Cloud platforms offload that work to a server, which is also why they can host far larger calls.

What is a signaling server, and can it spy on my call? It is a small relay that passes the initial introduction messages between two browsers so they can find each other. It never carries the actual audio or video, so it cannot see or hear your call.

The bigger picture

A browser video call looks like the simplest thing in the world: a link, a tab, a face. Underneath, it is a small symphony of web standards, media capture, a peer connection, encrypted data channels, an offer/answer handshake, ICE and STUN threading a path through the maze of NAT, and DTLS-SRTP locking the whole thing down, all cooperating to do something quietly radical: let two people talk without anyone in the middle.

That last phrase is the whole point. The default of the modern internet is a server in the middle of everything, and that server is where your data is seen, logged, and monetized. A peer-to-peer call removes the middle. Your conversation goes from you to them, encrypted, and then it is gone. It is the same conviction that runs through every privacy-first web app, explored further in the rise of privacy-first web apps and why your files should never leave your browser.

If a private, no-install, no-account call is what you need, start one and share the link. The same direct, encrypted, browser-to-browser approach powers peer-to-peer file sharing and real-time whiteboards. Same idea every time: straight from your device to theirs, and no one in between.