Why a v3 Onion Address Validates Itself

If you have spent any time around Tor hidden services, you have looked at an address that runs fifty-six characters long, followed by the literal suffix .onion, and you have probably wondered what is actually inside that string. The short answer is that the address is the service’s identity, expressed in a form the protocol can check on its own. A v3 onion address is self-validating. That single technical property changes how you should handle the address in practice, and it is worth understanding before you ever try to memorise one.

What is encoded in those characters

A v3 onion address has three parts, packed into a single base32 string of fifty-six characters before the .onion suffix. The first thirty-two bytes, before encoding, are the long-term public key of the hidden service. The next two bytes are a truncated checksum computed over the public key together with a small prefix and the version byte. The final byte is the version itself, currently 03. When you base32 encode those thirty-five bytes you get a fifty-six character lowercase string. Read the Tor Project documentation on onion service v3 for the formal specification.

The practical consequence of this packing is that the address is not arbitrary text that the operator picked. It is a derivation from the service’s keypair. You cannot register an onion address the way you register a domain. The service generates its keypair, and the public key is the address.

What “self-validating” means

When you paste a v3 onion address into the Tor Browser, the very first thing the client does is base32 decode it and check the checksum byte. If the checksum does not match what the public key bytes would produce, the client refuses to resolve the address. It does not try. It does not attempt a network lookup. It treats the address as malformed and tells you so.

This is the protocol-level reason fifty-six characters do not behave like a regular URL. With a clearnet domain, typing one wrong character usually gets you somewhere. Either nothing (NXDOMAIN), or a typo squat that someone registered to catch the mistake. With a v3 onion, typing one wrong character almost certainly breaks the checksum, and the client never even attempts the lookup. The probability that a random one-character substitution still passes the checksum is roughly one in sixty-five thousand.

The risk profile is therefore different from what people instinctively expect. The risk is not landing on a near miss because you typed o instead of 0. The risk is copying the wrong address from the wrong source in the first place, because if you do that the address validates fine and the client resolves to it.

What the protocol does after validation

Once the checksum passes, the client treats the public key as the service’s identity and uses it to look up the service descriptor. The descriptor is published periodically by the service to a small set of hidden-service directories, which are ordinary relays on the Tor network that have been elected to that role. The client fetches the descriptor from one of those directories, finds the rendezvous points the service is currently using, and connects through a chain of relays that no single party can fully see.

None of this is visible to you. You see the address bar, the page loading, and the result. The protocol does the heavy lifting between the keystroke and the screen. The address you provided is what anchors the entire process. Get the address right and everything else follows. Get the address wrong and there is nothing to anchor against.

What this implies for your handling

A few habits follow from the structure.

First, never type an onion address by hand. The string is the public key encoded for transport. Typing it accurately is mechanically possible and practically unreliable. Use the clipboard. Copy from the source, paste into the address bar.

Second, treat the source you copy from as the only point of failure. Once you have copied a string, the protocol will validate the checksum and either resolve cleanly or refuse to try. The dangerous step is the one before: where the address came from. A maintained directory that publishes the current address set, refreshes when the service rotates, and labels each entry clearly is the right shape of source. For a worked example of that shape, the Nexus Market directory publishes its onion set on a single page and updates it when the rotation moves.

Third, when you do paste an address, check at least the prefix. v3 onion addresses are long but human-recognisable at the first few characters. Operators usually register addresses that begin with something brand-relevant, and your eye will pick up an unfamiliar prefix faster than it will pick up a wrong character in the middle. This is not a substitute for using a trusted source; it is a free cross-check.

Fourth, do not screenshot onion addresses. Screenshots are a popular way to share addresses on chat platforms, and they undo every advantage the clipboard gives you. To use a screenshotted address you have to retype it, which is the failure mode the entire structure was designed to make unnecessary.

A small workflow

Open the directory you trust on the clearnet. Copy a current address from it. Switch to the Tor Browser and confirm the security slider is on Safest under the shield menu. Paste the address into the address bar and press Enter. If the page loads, you are done. If a challenge page appears, complete it without clicking around. If the address times out, return to the directory, copy the next address in the published set, and try that one.

That is the full workflow. It is short on purpose. The address handles its own validity check; the directory handles tracking which addresses are current; the Safest setting handles the browser-side attack surface. The only step left to you is to be consistent about where you copy from.

Further reading

For the user-facing side of the same problem (verification habits framed as a workflow), the companion piece on Medium covers it. For the related question of why services publish more than one address at a time, the mirror rotation explainer covers that side. The next page of this handbook covers how rotation is managed from the operator side.