Bencode Decoder & Torrent Inspector
Decode BitTorrent metadata and bencoded structures. Drop any .torrent file to extract announcers, piece layouts, file catalogs, and derive cryptographic info_hash values.
The BitTorrent Protocol Bencoding Specification (BEP 0003)
The Four Fundamental Bencode Data Types
Defined by Bram Cohen for the BitTorrent peer-to-peer protocol, bencoding is a simple binary-safe serialization format composed of 4 primitive types:
- Byte Strings: Encoded as
<length>:<string>. For instance,4:spamrepresents the 4-byte string "spam". - Integers: Encoded as
i<number>e. For instance,i42eis 42, andi-15eis -15. Leading zeros are prohibited. - Lists: Encoded as
l<items>e. Can contain arbitrary heterogeneous values, e.g.,l4:spami42ee→["spam", 42]. - Dictionaries: Encoded as
d<key1><val1>...e. Keys must be strings and sorted lexicographically according to raw bytes.
How the Torrent Info_Hash is Calculated
A torrent's identity on the Distributed Hash Table (DHT) and BitTorrent trackers is its 20-byte SHA-1 info_hash:
- Exact Byte Slicing: The hash is calculated exclusively over the raw bencoded byte stream of the
infodictionary (from openingdto closinge). - No Re-serialization: Modifying whitespace, key order, or encoding differences alters the SHA-1 digest, breaking peer swarms. Hence, compliant parsers must locate exact slice boundaries.
- Magnet Link BTIH: The
urn:btih:parameter in magnet links contains this exact 40-character hex string or 32-character Base32 string.
Why Not JSON or Protobuf?
JSON lacks binary safety (binary piece hashes would require Base64 bloat) and has no canonical key sorting rules, making consistent cryptographic hashing unreliable across different programming languages. Bencode achieves 100% deterministic serialization with minimal CPU overhead, which allowed early 2000s hardware to verify swarm integrity at line speed.