How URN BTIH Identifies BitTorrent v1 Info Hash

Magnet URIs rely on Uniform Resource Names (URNs) to identify files across decentralized peer-to-peer networks instead of pointing to a specific server location. In the BitTorrent ecosystem, the urn:btih namespace designates the “BitTorrent Info Hash,” which serves as the unique cryptographic fingerprint for a standard BitTorrent v1 torrent. This article explains how the urn:btih scheme operates within a magnet link, its encoding standards, and how clients interpret this identifier to locate and download content across the swarm.

The Role of urn:btih in Magnet Links

A standard magnet URI contains key-value pairs separated by ampersands. The most critical parameter is the “exact topic” (xt), which defines the unique content identifier. The urn:btih namespace specifically instructs the client that the following string is a BitTorrent v1 info hash.

A standard structure appears as follows:

magnet:?xt=urn:btih:<info-hash>

When a BitTorrent client parses this URI, the urn:btih: prefix informs the engine that the payload is not a generic file hash (such as SHA-256 or MD5), but a hash derived specifically from the info dictionary of a BitTorrent metainfo file.

How the v1 Info Hash is Generated

In BitTorrent v1, the info hash is a 160-bit (20-byte) cryptographic hash generated using the SHA-1 algorithm. The input for this hash is strictly the bencoded info dictionary from the torrent’s metadata, which contains:

• The piece length.
• The concatenation of all 20-byte SHA-1 piece hashes.
• File names, paths, and byte lengths.
• Torrent privacy flags.

Because any modification to the file contents, file order, or piece size alters the info dictionary, the resulting SHA-1 hash is unique to that specific dataset.

Encoding Formats: Hexadecimal vs. Base32

The 20-byte raw SHA-1 output must be converted into text to be safely transmitted in a URI. The urn:btih namespace accepts two standard string representations:

1. Hexadecimal (Hex): A 40-character string using characters 0–9 and a–f (case-insensitive). This represents 2 hex characters per byte (20 bytes × 2 = 40 characters).
2. Base32: A 32-character string using the standard Base32 alphabet A–Z and 2–7 (case-insensitive). Base32 encodes 5 bits per character (160 bits / 5 = 32 characters).

BitTorrent clients detect the length of the string after urn:btih: to determine the encoding format. If the string is 40 characters long, the client parses it as hex; if it is 32 characters long, it decodes it as Base32. Both representations yield the exact same 20-byte binary hash internally.

Swarm Discovery via the Info Hash

Once the 20-byte info hash is decoded from the urn:btih parameter, the client uses it to connect to the peer-to-peer network through several mechanisms:

• Distributed Hash Table (DHT): The client searches the Kademlia-based DHT for nodes whose Node IDs are mathematically closest to the info hash.
• Trackers: If tracker URLs are provided via the tr parameter in the magnet link, the client queries those trackers using the info hash.
• Peer Exchange (PEX): Once connected to initial peers, the client queries them for additional peers associated with that info hash.

Because the magnet link does not initially contain the full file metadata (such as individual file names or piece definitions), the client uses the BEP 9 (Extension for Peers to Send Metadata Files) protocol to download the actual info dictionary directly from connected peers. The client verifies the downloaded metadata against the urn:btih hash to ensure the data has not been modified or corrupted before downloading the actual files.