Anatomy of a v3 onion address: what the 56 characters actually encode
Every v3 onion address looks like keyboard noise: 56 lowercase letters and digits, ending in the letter d. That final character is not a coincidence, and neither is anything else in the string. Each of the 56 characters is computed from a short recipe in Tor's rendezvous specification, which turns a service's public key into exactly the address a Tor Browser will accept.
What the 56 characters actually encode
The encoding section of the rendezvous specification defines an onion address as the base32 encoding of precisely 35 bytes, followed by the .onion suffix:- Bytes 1-32: the service's ed25519 identity public key - the key whose private half signs everything the service publishes.
- Bytes 33-34: a checksum, taken as the first two bytes of SHA3-256 over the constant string ".onion checksum", the public key and the version byte.
- Byte 35: a version field, fixed at 0x03 for third-generation addresses.
The checksum that catches typos
The two checksum bytes exist because onion names have no registry, no WHOIS and no browser autocomplete to catch a slip. The design borrows from Bitcoin, whose Base58Check addresses append a similar hash-derived suffix; when Tor's developers proposed the format in early 2017, they laid out the arithmetic in a mailing list proposal:"In case of an address typo, we have 1/65536 probability to not detect the error."A single mistyped character changes the hash input, so the recomputed checksum almost never matches and the Tor client rejects the string as invalid before attempting any connection. Only about one error in 65,536 slips through, and a typo that survives the checksum lands on a random 32-byte key that almost certainly belongs to no service at all. The cost of that residual risk is two bytes; the alternative would be silent connections to whatever a mistyped address decodes to.
The address is the key: no certificate authority needed
On the ordinary web, a browser trusts that a name belongs to a key because a certificate authority says so. Onion addresses fold that vouching into the name itself. The 56 characters are the service's public key, so the address needs no registry and cannot be issued twice - two services cannot share one, because each address is a different key. Tor's onion service documentation describes how this plays out at connection time: the service publishes a descriptor signed with the private half of the key encoded in its address, and the client verifies that signature before ever building a circuit, confirming the descriptor "could only be produced by that Onion Service and no one else". This is what Tor's developers mean by self-authenticating. The Tor Project's 2021 overview of v3 services credits the same design with the format's privacy gains: directory relays handle only a blinded derivative of the identity key, so introduction points never learn the public key that the address spells out. Authentication, in other words, is not bolted on through a third party; it is present in every character.What a leaked private key means
Concentrating identity in one key concentrates risk in one file. Whoever obtains a service's private key can sign valid descriptors, answer introductions and impersonate the service completely - and nothing in the address will look wrong, because the attacker is using the genuine key. The checksum still passes, the signature still verifies; the impersonation is invisible to every client-side check the format offers."If your keys leak, other people can impersonate your Onion Service, deeming it compromised, useless, and dangerous to visit."Unlike a compromised password there is nothing to rotate: the address cannot change without abandoning it. Tor's setup guide treats the private_key file as the one secret that matters, warning operators to keep it private and to back it up securely if the service must outlive its hardware. For anyone tracking onion services from the outside, the practical lesson is that a structurally perfect address proves only that the string is intact - it says nothing about who holds the keys behind it today.
Verifying a checksum by hand
The whole verification fits in a few lines of any scripting language with SHA-3, and the steps follow directly from the spec:- Strip the .onion suffix and confirm that 56 base32 characters remain.
- Decode them into 35 bytes: the first 32 are the public key, the next two are the checksum and the last is the version byte.
- Feed SHA3-256 the constant string ".onion checksum", then the 32 key bytes, then the version byte.
- Compare the first two bytes of the digest with the checksum bytes. A match means the string was copied correctly.