What Is WebRTC? A Plain-English Explanation

If you’ve ever joined a video call in your browser without installing anything, you’ve used WebRTC. It’s also what lets BoltShare send a file straight from one browser to another.

The name stands for Web Real-Time Communication. It’s a set of features built into every modern browser (Chrome, Firefox, Safari, Edge) that lets two browsers talk to each other directly, rather than everything going through a website’s servers.

That sounds simple. The interesting part is everything that has to happen before two browsers can actually find each other.

The problem: your computer doesn’t have an address

When you visit a website, your browser connects to a server that has a public address anyone can reach. Easy.

Two home computers can’t do that with each other. Your laptop has a private address that only makes sense inside your home network, something like 192.168.1.23. Your router hides it behind the single public address your internet provider gave you. Your friend’s laptop is hidden the same way.

So neither browser knows how to reach the other. And even if it did, both routers would normally block an unexpected incoming connection. WebRTC exists to solve exactly this.

Step 1: an introduction (signaling)

First, the two browsers need to swap some basic information: “here’s who I am, here’s what I can do, here’s how you might reach me.”

WebRTC deliberately doesn’t say how to swap it. Each app brings its own way. BoltShare uses a small signaling server: the sender’s browser registers a session, you share the link, and when the receiver opens it, the server passes messages back and forth between them until they’re connected. It’s the go-between that introduces two strangers at a party, then steps away.

Step 2: “what do I look like from outside?” (STUN)

Your browser doesn’t actually know its own public address. It only knows the private one. So it asks a STUN server, which is basically a mirror on the internet. The browser sends a tiny message and the STUN server replies, “this came from public address X, port Y.”

Now each browser knows roughly how it looks to the outside world, and they swap that through the signaling server.

Step 3: knock on both doors at once (ICE and hole punching)

Here’s the clever bit. Both browsers start sending packets to each other’s public addresses at the same time.

When your router sees your laptop send a packet out to your friend’s address, it makes a note: “we’re expecting replies from there.” So when your friend’s packet arrives a moment later, your router lets it in, because it looks like a reply. The same happens on their side. This is called hole punching.

The process of trying all the possible routes (local network, public address, relay) and picking the best one that works is called ICE. If you’re both on the same Wi-Fi, ICE usually finds the local route and the data never leaves the building.

Step 4: when there’s no way through (TURN)

Hole punching doesn’t always work. Strict corporate firewalls and some mobile networks (see why some networks block direct transfers) break it.

The fallback is a TURN server, a relay both sides can reach, which forwards the packets between them. The data is still encrypted end to end, so the relay can pass it along but can’t read it.

BoltShare’s Bolt Tunnel mode is a similar idea, built for big files. Both browsers connect outward to our relay over a regular secure web connection, which works almost everywhere. This post covers how the two compare.

Step 5: the actual data (data channels and DTLS)

Once a route is found, WebRTC opens a data channel, a pipe for sending arbitrary data (files, game moves, chat messages) rather than audio and video.

Everything sent over WebRTC is encrypted using DTLS, the same family of encryption as the HTTPS padlock in your address bar. The encryption keys are created by the two browsers themselves, so anyone sitting between them (your Wi-Fi provider, an internet backbone, a TURN relay) just sees scrambled data.

Why it matters for file sharing

Before WebRTC, sending a file from one browser to another meant uploading it to a server first, waiting, then downloading it on the other side. WebRTC removes the middle step:

• No upload wait. The receiver starts getting data the moment you start sending.
• No storage. There’s no server copy to forget about or worry about.
• No size cap from storage costs. The service isn’t paying to store your 80 GB file, so it has no reason to limit it.

The trade-off is that both people need to be online at the same time, and the sender has to keep the tab open. For a lot of transfers, that’s a fair deal.