TORRENT File Documentation

---

Technical details

Feature	Value
Full name	BitTorrent Metainfo File
File extension	.torrent
MIME type	application/x-bittorrent
Format type	Bencoded text metadata (no executable content)
Developer	BitTorrent (originally Bram Cohen)
Introduced	2001 (BitTorrent protocol; BEP-3)
Standard / spec	BEP-3 (v1); BEP-52 (v2)
Open standard	Yes
Encoding	Bencode (dictionaries, lists, integers, byte strings)
First byte	0x64 ("d", start of a bencoded dictionary)
Typical start	d8:announce
Top-level keys	announce, announce-list, info, creation date
Piece hash (v1)	SHA-1, 20 bytes per piece
Piece hash (v2)	SHA-256
Contains the media	No — only metadata and hashes
Alternative	Magnet link (carries the infohash directly)
Opened by	qBittorrent, Transmission, BitComet, uTorrent
Related extensions	.magnet, .!ut, .aria2
Specification URL	BEP-3

What is a .torrent file?

A .torrent file is the metainfo file of the BitTorrent peer-to-peer protocol, defined by BitTorrent Enhancement Proposal 3 (BEP-3) in 2001. The most important thing to understand is what it does not contain: it holds none of the media you want to download. Instead it is a compact index describing the target content and where to find peers who have it. Its MIME type is application/x-bittorrent.

A .torrent records four things: the name and size of the file or files, how that data is cut into fixed-size pieces, a cryptographic hash of every piece so the download can be verified, and one or more tracker URLs used to locate other peers. Because it is plain structured text with no code, a .torrent itself cannot run or carry a virus. You open it in a BitTorrent client, which reads this metadata and then fetches the real content from many peers at once.

Bencode: the encoding every torrent uses

The entire file is serialised in bencode, a deliberately simple text format with exactly four value types. Once you know the four rules you can read a torrent by hand.

Integer      i<number>e            e.g.  i42e        => 42
Byte string  <length>:<bytes>      e.g.  4:spam      => "spam"
List         l <values...> e       e.g.  l4:spam4:eggse => ["spam","eggs"]
Dictionary   d <key value...> e    e.g.  d3:cow3:mooe  => {"cow":"moo"}

Integers sit between i and e in base 10 and may be negative. A byte string is a base-10 length, a colon, then exactly that many bytes — there are no escape characters, which is why bencode can hold arbitrary binary data (like the raw piece hashes) safely. Lists and dictionaries are bracketed by l…e and d…e. A dictionary's keys must be byte strings and must appear in sorted (lexicographic) order, a rule that matters enormously, as the next section explains. The whole file is one dictionary, so it always starts with d and ends with the matching e.

The top-level dictionary: announce and info

The outer dictionary has a handful of well-known keys. In sorted order they typically run announce, announce-list, comment, created by, creation date, then info.

Key	Meaning
announce	The primary tracker URL used to find peers
announce-list	Optional list of backup and additional trackers
comment	Free-text note from whoever made the torrent
created by	Name and version of the tool that generated the file
creation date	Creation time as a Unix timestamp (integer)
info	The dictionary describing the actual content (see below)

The tracker is a server that keeps a list of peers currently sharing a torrent; the client "announces" itself to that URL and receives peers in return. Modern torrents often supplement or replace trackers with the distributed hash table (DHT), a trackerless peer-discovery network, which is why some .torrent files have no announce key at all and begin instead with d7:comment or d4:info.

The info dictionary: name, piece length and pieces

The info dictionary is the core of the file. It describes the content itself and is the same for everyone sharing that content, which makes it the torrent's identity.

info => d
  6:length      i1048576e            (single-file size in bytes)
  4:name        11:ubuntu.iso        (suggested file/folder name)
  12:piece length i262144e           (bytes per piece, here 256 KiB)
  6:pieces      <N x 20 raw bytes>    (concatenated SHA-1 hashes)
e

The content is split into equal-sized pieces whose length is given by piece length (commonly a power of two such as 256 KiB or 1 MiB). For each piece, the creator computes a 20-byte SHA-1 hash, and all those hashes are concatenated into a single byte string under the pieces key. So a torrent for a file of 100 pieces carries a pieces string of exactly 2000 bytes. As a client downloads each piece from whatever peer supplies it, it hashes the bytes and compares them against the stored hash, rejecting any piece that has been corrupted or tampered with. This per-piece verification is what makes swarming from untrusted strangers reliable. BitTorrent v2 (BEP-52) upgrades the hash to SHA-256 and uses a Merkle-tree layout, but the v1 SHA-1 scheme above is still the common case.

Single-file versus multi-file torrents

A torrent can describe one file or a whole directory tree. In a single-file torrent, info has a length key with the file's size. In a multi-file torrent, info instead has a files key: a list of dictionaries, one per file, each carrying that file's length and a path (itself a list of path components). In the multi-file case the pieces are computed across the concatenation of all files in order, so a single piece can straddle the boundary between two files. The name key then names the containing folder rather than a single file.

The infohash: how a torrent identifies content

A torrent's true identity is not its filename but its infohash: the SHA-1 hash of the bencoded info dictionary, computed over the exact bytes as they appear in the file. This is why bencode's sorted-key and canonical-encoding rules matter so much — two files that encode the same info differently would hash differently and be treated as different torrents. The infohash is what a client sends to trackers and to the DHT to find peers, and it is what a magnet link carries directly. A magnet URI such as magnet:?xt=urn:btih:<infohash> needs no .torrent file at all, because the client can fetch the full info dictionary from the swarm using just that hash. Opening a magnet and exporting a .torrent (or generating a magnet from an added torrent) are simply the same identity viewed two ways.

From metadata to an actual download

When you open a .torrent in a client, the client reads the trackers and the DHT to assemble a list of peers who hold the content. It then requests pieces from many peers simultaneously, and as it obtains pieces it also uploads the ones it already has to others (this is "seeding"). Each incoming piece is checked against its hash from the pieces string before being accepted, so tampered or damaged data never reaches your disk unnoticed. None of this logic lives in the .torrent; the file only supplies the map. That is also why "converting" a torrent to an MP4 or MP3 is meaningless — there is no media inside to convert, only hashes and tracker addresses.

Is the file dangerous, and is it legal?

The .torrent file itself is inert bencoded text: it contains no executable code and cannot run anything, so opening and inspecting one is safe. The risk lives entirely in what you download with it. Torrented content can be malware, mislabelled, or copyrighted, so scan any downloaded executables and prefer trusted sources. Legality follows the content, not the format: distributing a Linux ISO, an Internet Archive item or an open dataset by torrent is entirely lawful, while downloading copyrighted films or software is illegal in most countries. Two practical notes: use a reputable open-source client (qBittorrent, Transmission) and avoid ones with bundled adware, and be aware that your IP address is visible to the other peers in a swarm.

Frequently asked questions

What is the difference between a .torrent file and a magnet link?

A .torrent file stores the full metadata (including the info dictionary and piece hashes) locally. A magnet link is just a URL carrying the infohash, from which the client fetches that same metadata over the DHT. Both end up downloading identical content; the magnet simply skips the intermediate file.

References

• BitTorrent.org — BEP-3, The BitTorrent Protocol Specification
• qBittorrent — free, open-source, ad-free client
• Transmission — lightweight BitTorrent client

Feedback

Was this page helpful?

Yes No

Glad to hear it! Please tell us how we can improve.

Sorry to hear that. Please tell us how we can improve.