Bencode decoder: the format with exactly one right answer

What is bencode?

Bencode is the encoding BitTorrent uses for .torrent files and tracker traffic. It has four types and no punctuation to speak of: a string is its length, a colon and the bytes, so 4:spam is the word spam; an integer is i, the digits and e; a list is l, its contents and e; a dictionary is d, alternating keys and values, and e. That is the whole format.

What makes it unusual is that it is canonical by construction. The specification requires dictionary keys to appear in sorted order, forbids i-0e, and forbids any integer with a leading zero. Between them those rules mean a given value has exactly one valid encoding — there is no whitespace to vary, no ordering to choose, no way to write the same number two ways.

That property is the reason bencode was chosen. A torrent is identified by the SHA-1 of its info dictionary, so the encoding has to be reproducible byte for byte or the identity is not stable. This page decodes what you paste, shows every rule it breaks, and computes that hash the way the specification requires.

How to use it

1. Paste bencode, or open a .torrent. The file is read in your browser and never uploaded. Byte values that are not printable are summarised rather than mangled, and nothing is lost on the way through.
2. Read the verdict and the findings. There are two separate questions: whether the input breaks a stated rule, and whether re-encoding it would give back the same bytes. Each finding says which rule and where.
3. Compare the two info-hashes. One is taken from the original bytes, the other from a decode and re-encode. If they differ, you are looking at the bug the specification warns about.

Why a re-encode can change a torrent's identity

The info-hash is not a hash of the torrent's contents in any abstract sense. It is the SHA-1 of the bytes of the info dictionary exactly as they appear in the file. So if a program decodes a torrent and encodes it again, and the original was not perfectly canonical, the bytes change and the hash changes with them — and the hash is what trackers and peers use to identify the torrent at all.

The specification anticipates this in unusual detail. It says the info-hash is what you get by decoding and re-encoding only if the decoder fully validated the input, mentioning key ordering and leading zeros by name. It then says clients must either reject invalid files or take the substring directly, and that they must not perform a decode-encode round trip on invalid data. Specifications do not normally spend a paragraph on a hypothetical.

It is not hypothetical. A widely used bencode library was tested against the five forms the specification declares invalid while this page was built: keys out of order, a duplicate key, i-0e, i03e and i-03e. It accepted every one, re-encoded each to different bytes, and produced a different SHA-1 in all five cases. A valid document round-tripped through the same library byte for byte with an unchanged hash, which is what makes those five the library's behaviour rather than a quirk of the test.

This page therefore computes the hash from a slice of the bytes you gave it, never by re-encoding, and shows the re-encoded one beside it only so you can see the two come apart.

Valid and canonical are different questions

It is tempting to test a bencode document by decoding it, encoding it again, and checking the bytes match. That catches unsorted keys and leading zeros, and it is the check most tools would reach for. It does not catch everything.

A dictionary with the same key twice breaks the sorted-order rule, because sorted order leaves no room for a repeat. But a decoder that keeps both entries will write both back out in the same places, and the bytes come back identical. The round trip says the document is fine; the specification says it is not. So this page answers the two questions separately and says which is which.

There is also a rule the specification does not state. It forbids leading zeros in integers and gives i0e as the single exception, but it describes a string only as length-prefixed base ten and says nothing about how that length may be written. A string introduced as 03:abc is therefore odd rather than illegal, and this page reports it as an observation without counting it against the verdict. Where the specification declines to rule, so does the page.

What this cannot tell you

It cannot tell you whether a torrent is safe, complete, or points anywhere useful. It reads structure, not meaning: the piece hashes are just byte strings to it, and it makes no attempt to check them against anything. A file can be perfectly canonical bencode and still be a torrent for something you do not want.

It also makes no claim about any particular BitTorrent client. The specification says what a client must do; what any one of them actually does is not something this page can observe, and nothing here has been tested against one.

Finally, bencode is a byte format rather than a text format. A key or value can contain any byte at all, including ones that are not valid text in any encoding, and the piece hashes in a real torrent are exactly that. This page keeps every byte intact through the round trip, and where a value cannot be shown as text it says how many bytes it is instead of guessing at characters that are not there.

Why is it free?

Decoding bencode is string handling, and hashing is something your browser already does. There is no server in the loop, so there is nothing to bill for and no account to create.

Nothing is uploaded. A .torrent you open is read locally and never leaves the tab, which matters here more than usual.