How Does BitTorrent Work? A Plain-English Guide

The easiest way to understand BitTorrent is to follow one real torrent from start to finish. This guide uses Sintel, Blender's 2010 open movie, which is licensed under Creative Commons Attribution and is shared as an official torrent. Its torrent holds a 129 MB MP4 file, ten subtitle files, and a poster. The torrent splits all of that into 987 pieces of 128 KiB each.
Here is the whole process in five steps. The rest of the post takes each one apart.
- You get a description of the content. That is the torrent file or a magnet link. It names the files and lists a fingerprint for every piece.
- Your client finds other people sharing it. It asks trackers, the DHT, and peers it already knows.
- It connects to them and they compare notes. Each side says which pieces it has.
- They trade pieces. You download pieces you lack and upload pieces you have, many peers at once.
- Every piece is checked against its fingerprint before it is kept. When all pieces pass, the file is complete, and you can keep sharing it (seeding).
What a torrent is
A torrent file is not the movie. It is a small description of the movie. Sintel's torrent file is about 20 KB, and most of that is fingerprints.
The format is defined in BEP 3, the original BitTorrent specification (BEPs, BitTorrent Enhancement Proposals, are the protocol's numbered specification documents). The heart of a torrent file is a section called info, which contains:
name: the suggested name of the file or folder.piece length: how big each piece is. BEP 3 says the most common size is 256 KiB. Sintel uses 128 KiB.lengthorfiles: the size of a single file, or a list of files with their paths and sizes.pieces: one 20-byte SHA-1 hash for every piece, all joined together. For Sintel that is 987 × 20 = 19,740 bytes.
Outside info, a torrent file usually lists one or more trackers and may add a comment, the creating program, and web seeds (ordinary web servers that hold the same files).
The info hash: the torrent's identity
Take the info section exactly as it is stored and run it through SHA-1. The result is the info hash, a 20-byte number usually written as 40 hexadecimal characters. Sintel's is:
08ada5a7a6183aae1e09d831df6748d566095a10
The info hash is how every part of BitTorrent refers to a torrent. Trackers index swarms by it, the DHT looks it up, peers confirm it when they connect, and a magnet link is little more than the info hash with a name attached. Change a single byte of the file list or the piece hashes and you get a completely different info hash, and so a different swarm.
So what is "torrenting"?
"Torrenting" just means using BitTorrent: downloading and uploading pieces of a torrent with other people. Everyone sharing one torrent forms the swarm. Those with the complete file are seeders; those still downloading are leechers, or simply peers.
Pieces and hashes: why you can trust strangers
Your client never has to trust a peer. When a piece arrives, the client hashes it and compares the result with the hash for that piece in the torrent. If they match, the piece is exactly what the torrent's creator published. If they do not, the piece is thrown away and fetched again, possibly from someone else. A peer cannot slip in a modified piece without the hash failing.
Pieces are also the unit of trade. Because the file is split into hundreds or thousands of pieces, you can download piece 12 from one peer, piece 340 from another, and upload piece 7 to a third, all at the same time. A piece is fetched in even smaller blocks of 16 KiB, and clients keep several block requests queued with each peer so the connection never sits idle.
Finding peers
Before your client can trade, it needs addresses of other peers in the swarm. There are three main ways to get them, and modern clients use all three.
Trackers
A tracker is a server that keeps a list of peers for each info hash. Your client announces to it: it sends the info hash, a random peer ID, the port it listens on, and how much it has uploaded, downloaded, and has left. The tracker replies with a list of peers and an interval, the number of seconds to wait before announcing again.
The tracker never touches the file itself. It only introduces peers to each other. Trackers come in two flavours: HTTP trackers from BEP 3, and lighter UDP trackers from BEP 15. Most trackers send peers in a compact form (BEP 23) that packs each address into a few bytes. A torrent can list several trackers as backups (BEP 12).
The DHT
A tracker is a single point of failure. If it goes offline, nobody can find anyone. The distributed hash table (DHT, BEP 5) removes that dependency. In the specification's words: "In effect, each peer becomes a tracker."
The DHT is based on a design called Kademlia and runs over UDP. Every participating client is a node with a random 160-bit ID, drawn from the same space as info hashes. "Distance" between two IDs is calculated with XOR, and each node remembers more nodes close to its own ID than far from it.
To find peers for Sintel, your client asks the nodes it knows that are closest to Sintel's info hash. They reply either with peers or with nodes that are closer still. Your client repeats this until it reaches the nodes responsible for that info hash, which hand over the peers they know. Then your client announces itself to those nodes, so the next person finds you. It is a phone tree with no central directory.
Peer exchange
Once you are connected to a few peers, the simplest source of new ones is them. Peer exchange (PEX, BEP 11) lets connected peers tell each other which peers they are connected to. The spec limits it to one message a minute and about 50 added and 50 dropped peers per message, and it only lists peers someone has actually connected to, so the addresses tend to be live. PEX cannot start a download on its own, because you need one peer first, but it keeps your peer list fresh once the trackers or the DHT have got you going.
How peers talk: the peer wire protocol
Peers talk to each other over TCP, or over uTP (BEP 29), a UDP-based transport whose stated motivation is "for BitTorrent clients to not disrupt internet connections": it backs off when it detects other traffic on your line. The messages are the same either way.
The handshake
The connection opens with a handshake. Each side sends the string BitTorrent protocol, eight reserved bytes that advertise optional features, the info hash, and its peer ID. If the info hashes do not match, the connection is dropped. That is how two peers confirm they are in the same swarm.
The messages
After the handshake, everything is a short message. BEP 3 defines nine:
| Message | What it means |
|---|---|
bitfield | "Here is a map of every piece I have" (sent once, right after the handshake) |
have | "I just finished piece N" |
interested | "You have something I want" |
not interested | "You have nothing I need" |
choke | "I will not upload to you for now" |
unchoke | "Go ahead, you can request from me" |
request | "Send me this 16 KiB block of piece N" |
piece | "Here is the block you asked for" |
cancel | "Never mind that request" |
A typical exchange goes like this. Your client receives a peer's bitfield, sees that it has pieces you lack, and sends interested. When the peer sends unchoke, your client starts sending request messages and the peer answers with piece messages. Whenever you complete and verify a piece, you send have to all your peers, so they know they can now ask you for it.
Later additions ride on the same connection. The extension protocol (BEP 10) uses one of the reserved handshake bits to signal support for extra messages; peer exchange and magnet-link metadata transfer both use it.
Choking and tit-for-tat
Every client has limited upload bandwidth, so it has to decide whom to upload to. BitTorrent's answer is a choking algorithm. Bram Cohen, who designed the protocol, described it in his 2003 paper Incentives Build Robustness in BitTorrent as "a variant of tit-for-tat": you upload to peers who upload to you. "Choking is a temporary refusal to upload," he wrote; the connection stays open, and downloading in the other direction can continue.
The rules from BEP 3 and Cohen's paper:
- Unchoke the best uploaders. A downloading client unchokes the peers that are giving it the best download rates, four by default in the original design.
- Re-decide every 10 seconds. Choking and unchoking too often wastes bandwidth, and ten seconds is long enough for a TCP connection to reach full speed.
- One optimistic unchoke. One extra peer is unchoked regardless of its rate, and that slot rotates every 30 seconds. This is how new peers, who have nothing to offer yet, get their first pieces, and how your client discovers peers faster than its current ones. New connections are three times as likely to get the slot. Cohen compares it to "always cooperating on the first move" in the prisoner's dilemma.
- Anti-snubbing. If a peer has not sent you anything for over a minute, your client treats itself as snubbed by it and stops uploading to it except as an optimistic unchoke.
- Seeders choose differently. A seeder downloads nothing, so it ranks peers by how fast it can upload to them.
Peers that share generously get better download speeds; free riders get only what optimistic unchokes and seeders give them.
Which piece to download next
Cohen's paper sets out four rules for choosing pieces that most clients still follow:
- Random first piece. A new peer grabs a random piece so it has something to upload quickly.
- Rarest first. After that, it fetches the pieces the fewest of its neighbours have, which spreads every piece across the swarm.
- Strict priority. Once one block of a piece is requested, the rest of that piece comes first, so pieces complete quickly.
- Endgame mode. At the very end, the last blocks are requested from every peer at once, with cancels sent as copies arrive, so one slow peer cannot hold up the finish.
Rarest first keeps a swarm healthy, and it is the rule streaming has to bend. Sequential download explained covers why.
Seeding
When every piece has passed its hash check, your client becomes a seeder. It keeps answering request messages and uploading pieces to the peers who still need them, until you stop it.
Seeders are what keep a torrent alive. A swarm can survive for a while on leechers trading pieces among themselves, but if nobody holds a complete copy and some piece exists on no connected peer, nobody can finish. That is a common reason a torrent sits at 99.9% for ever. Seeding and ratio explained covers how long to seed and what a ratio means.
Magnet links
A magnet link is a torrent without the torrent file. It looks like magnet:?xt=urn:btih: followed by the info hash, often with a display name (dn) and some trackers (tr). Per BEP 9, the info hash is the only required part.
A magnet link has no piece hashes or file list, so your client uses the info hash to find peers (through the listed trackers or the DHT) and downloads the info section from them in 16 KiB chunks, using the ut_metadata extension. It hashes the result and compares it with the info hash in the link, so a peer cannot hand over a fake file list. Then the download proceeds exactly as with a torrent file.
That step is the "retrieving metadata" message in your client. If it never finishes, your client has not found a peer with the metadata; retrieving metadata stuck covers the usual fixes, and what is a magnet link explains the format in more detail.
BitTorrent v2 in brief
The original protocol hashes whole pieces with SHA-1. According to libtorrent's write-up, work on v2 began as an effort to move away from SHA-1, shortly after Google announced it had produced a SHA-1 collision. BEP 52, the v2 specification, changes both:
- SHA-256 replaces SHA-1 for piece verification and for the info hash. Where a 20-byte identifier is still needed, such as in the peer handshake, the 32-byte v2 info hash is truncated to 20 bytes.
- A hash tree per file. Each file gets its own Merkle tree built from 16 KiB blocks. libtorrent's announcement of v2 support points out that a corrupt block "can be discovered immediately and only 16 kiB need to be re-downloaded", and the peer that sent it can be identified for certain.
- Files are aligned to pieces. Every file starts on a piece boundary, and, per the spec, "identical files always result in the same root hash", so the same file can be recognised across different torrents.
- Hybrid torrents carry both a v1 and a v2 info hash, so old and new clients can share one swarm. v2 magnet links use
urn:btmh:instead ofurn:btih:.
BEP 52 is still marked Draft on bittorrent.org, but major software supports it: libtorrent added it in version 2.0 in 2020, and qBittorrent added support for v2 torrents in 4.4.0 in January 2022.
Is torrenting legal?
BitTorrent itself is legal. What can be illegal is the content: downloading or sharing copyrighted films, shows, games, or software without permission usually is. Two protocol details matter here: while you download you are also uploading to others, and every peer in the swarm can see your IP address, because that is how they connect to you. Is torrenting legal? covers the general principles; it is not legal advice.
How streaming changes the picture
Everything above is designed to finish a whole download as efficiently as possible, for you and for the swarm. Watching a video while it downloads has a different goal: the piece you need is the one under the playhead, not the rarest one.
So streaming apps change how pieces are picked, not how BitTorrent works: the handshake, messages, hashes, and peer discovery stay the same. A plain client in sequential mode simply downloads pieces in file order. A player built for streaming follows the playhead instead. TorrentPlayer, the free and open-source player we make, requests the pieces at the playhead first, then the file's index, then a read-ahead window sized from the video's bitrate. When you skip, it cancels requests that are no longer urgent and duplicates the most urgent blocks to a second peer, much like endgame mode applied at the playhead.
Sequential download explained covers the trade-offs of downloading in order, and how to stream a torrent without downloading it first covers the practical ways to watch one.
Sources
- BEP 3, The BitTorrent Protocol Specification
- BEP 5, DHT Protocol
- BEP 9, Extension for Peers to Send Metadata Files
- BEP 10, Extension Protocol
- BEP 11, Peer Exchange
- BEP 12, Multitracker Metadata Extension
- BEP 15, UDP Tracker Protocol
- BEP 23, Tracker Returns Compact Peer Lists
- BEP 29, uTorrent Transport Protocol
- BEP 52, The BitTorrent Protocol Specification v2
- Index of BEPs and their status
- Bram Cohen, Incentives Build Robustness in BitTorrent (2003)
- libtorrent blog, BitTorrent v2
- qBittorrent changelog (v4.4.0, v2 torrent support)
- WebTorrent free torrents (Sintel torrent file)
- Sintel: About (licence)
- TorrentPlayer on GitHub
Checked on 20 October 2026.