WebTorrent
WebTorrent is a BitTorrent implementation written in JavaScript that runs inside a web page, moving data between browsers over WebRTC instead of the plain TCP and UDP connections a desktop client uses. It speaks the same torrent format, the same info hashes, the same 16 KiB block requests and the same piece verification as any other client, and the one thing it changes is the transport. That change is not a detail: it decides who a browser peer is able to talk to, and it is the reason a page can join a swarm at all when a browser is forbidden from opening an ordinary socket.
What WebRTC changes about who a browser may talk to
WebRTC changes the transport, and everything else follows from it. A page in a browser cannot open a raw TCP connection to an arbitrary address, because the browser sandbox does not allow it, and no amount of JavaScript works around that. WebRTC is the exception the browser does allow: a peer connection between two browsers, negotiated in advance, encrypted by design with DTLS, and carrying arbitrary bytes on a data channel once established. WebTorrent uses that data channel exactly where a desktop client would use a TCP connection to a peer.
The negotiation is the cost. Two WebRTC endpoints cannot simply find each other: each has to exchange a session description and candidate addresses through some third party before any direct connection exists, a step called signaling. WebTorrent solves it with trackers that speak WebSocket rather than the HTTP and UDP announce that desktop clients use, so a browser peer announces to a tracker built for browsers and receives introductions rather than a plain list of addresses. Where a desktop swarm can fall back on a distributed hash table and peer exchange, a browser tab depends on that signaling path being available.
Why a browser swarm and a desktop swarm are not the same swarm
A browser swarm and a desktop swarm share the same 20 byte info hash and still cannot reach each other, because a peer that speaks only TCP has no way to accept a WebRTC connection and a browser has no way to make a TCP one. Two groups of people can therefore be transferring the identical torrent, with identical piece hashes, in two populations that never meet. This is the single most common surprise: a torrent with many peers on the ordinary network can show none at all in a browser.
The bridge is a client that implements both transports. WebTorrent Desktop is the obvious one, and any client that adds WebRTC peer support joins the two sides for as long as it is running. Without such a bridge, a browser swarm is only as large as the number of tabs open on that page at that moment, which is why browser transfers feel healthy on a busy page and stall on a quiet one. The swarm page covers how peer counts behave in general, and the arithmetic there applies here with the extra condition that only WebRTC capable peers count.
What WebTorrent Desktop does that a page cannot
WebTorrent Desktop is a standalone application built on the same JavaScript implementation, wrapped so that it can do the things a page is not permitted to do. Because it is a desktop process it listens on ordinary ports as well as speaking WebRTC, so it sits in both swarms at once. It writes to a real folder rather than to browser storage, it keeps running when no window has focus, and it can go on seeding after the transfer completes, which a closed tab cannot.
Its visible feature is streaming. WebTorrent Desktop requests pieces in an order suited to playback rather than by rarity, so a video begins playing while the rest is still arriving, and it plays into a built in player or casts to a device on the network. The trade is the one sequential downloading always makes: asking for pieces in order is worse for the swarm than asking for rare pieces first, so a streaming client is a weaker contributor than a conventional one.
WebTorrent Desktop compared with a page using WebTorrent
WebTorrent Desktop and an in browser player are two different answers, and the confusion between them is about what each one is for rather than about how each moves bytes.
| Property | WebTorrent Desktop | A page using WebTorrent |
|---|---|---|
| What it is | A torrent client with a player | A web page |
| Where content comes from | A torrent or magnet link you supply | Whatever the page itself offers |
| Transports spoken | WebRTC and ordinary TCP and UDP | WebRTC only |
| Seeds after you finish | Yes, while the app runs | Only while the tab is open |
| Where files land | A folder you choose | Browser storage, temporarily |
One further route exists in the browser itself, since one major browser, Brave, has shipped built in WebTorrent handling so that a magnet link opens in a tab rather than handing off to a desktop program.
What WebTorrent is good for, and where it stops
WebTorrent is good wherever the point is that no installation should be required, and it stops wherever persistence is required. It suits a project distributing its own large files from its own page, a demonstration, a live stream fanned out between viewers, or a site that wants readers to share the load of a heavy asset. It suits long term availability badly, because a peer that exists only while a tab is open is not a seed in any durable sense, and the moment everyone closes the page the content is gone unless an ordinary client is holding it.
WebTorrent moves the same protocol, first described in 2001, into a place it could not previously reach, and pays for that with a smaller peer population and no persistence. Every generation of peer to peer has been shaped by where its program was allowed to run, from the dedicated application Napster required in 1999 to a tab that closes. For a folder that must stay identical across your own machines, Syncthing is the tool with the right shape, and the Glossary defines the terms all of them share.