Magnet Links, Info Hashes, and Torrent Payloads

BitTorrent relies on a precise cryptographic and structural hierarchy to identify, locate, and verify files across a decentralized network. This article explains the structural relationship connecting the user-facing magnet URI, the cryptographic info hash, and the ultimate data payload transferred between peers.

The Hierarchy: From Data to Link

The relationship among these three components is hierarchical and cryptographic, moving from raw data to a network identifier:

Payload: The actual target files.
Metadata (Info Dictionary): The blueprint mapping the payload into verifiable chunks.
Info Hash: A cryptographic digest identifying the metadata.
Magnet URI: A formatted string that wraps the info hash with bootstrap network parameters.

[Torrent Payload] (Files / Data Chunks)
       ▲
       │ Verified by piece hashes inside
       ▼
[Info Dictionary] (File paths, lengths, piece length, piece hashes)
       ▲
       │ Cryptographically hashed (SHA-1 or SHA-256)
       ▼
  [Info Hash] (Unique 20-byte / 32-byte identifier)
       ▲
       │ Embedded via 'xt=urn:btih:' parameter
       ▼
 [Magnet URI] (magnet:?xt=urn:btih:<info_hash>&dn=...&tr=...)

1. The Torrent Payload

The payload is the final collection of files or directories requested by the user.

In the BitTorrent protocol, the payload is treated as a continuous byte stream divided into fixed-size segments called pieces (typically between 256 KB and 16 MB). Each individual piece is cryptographically hashed to allow independent verification during the download process.

2. The Info Dictionary and the Info Hash

To describe the payload, a .torrent file contains a specific structure called the info dictionary (encoded in Bencode format). The info dictionary contains:

The name of the file or root directory.
Total file sizes and relative directory paths.
The uniform piece length.
A concatenated list of the cryptographic hashes of every individual payload piece.

The info hash is created by taking the raw Bencoded info dictionary and computing its cryptographic hash:

BitTorrent v1: SHA-1 hash (20 bytes / 40 hexadecimal characters).
BitTorrent v2: SHA-256 hash (32 bytes / 64 hexadecimal characters).

Because the info hash is a digest of the metadata—which itself contains the hashes of all payload pieces—any modification to a single byte in the payload or file structure produces a completely different info hash. This makes the info hash an immutable, globally unique identifier for that specific dataset.

3. The Magnet URI

A Magnet URI (Uniform Resource Identifier) is a standardized text string that allows peers to join a BitTorrent swarm without needing to pre-download a static .torrent file.

The structural core of every BitTorrent magnet link is the Exact Topic (xt) parameter, which directly embeds the info hash:

magnet:?xt=urn:btih:d3b07384d113edec49eaa6238ad5ff00fc19d7d1&dn=Ubuntu+ISO&tr=https%3A%2F%2Ftracker.example.com

xt=urn:btih: (or urn:btmh: in v2): Contains the info hash that uniquely identifies the swarm.
dn (Display Name): An optional human-readable title (does not affect file integrity).
tr (Tracker): Optional tracker URLs used to locate initial peers.

The Resolution Process in Practice

When a BitTorrent client processes a download, the relationship operates in reverse:

Extraction: The client reads the magnet URI and extracts the info hash.
Discovery: The client uses the info hash to query Distributed Hash Tables (DHT) or trackers to find peers hosting that exact hash.
Metadata Exchange: Through peer-to-peer extension protocols (such as BEP 9), the client downloads the raw info dictionary from connected peers and validates it by confirming its hash matches the info hash from the magnet link.
Payload Acquisition: With the validated info dictionary in hand, the client downloads the payload pieces from the swarm, validating each piece against the hash table embedded inside the info dictionary.