Onion Addresses Explained: Why Dark Web Links Rotate and Expire

What a .onion address actually is

A v3 onion address is the base32 encoding of a 32-byte ed25519 public key, a checksum and a version byte, which is why it always runs to 56 characters. There is no separate identity behind it and no registry that issued it. The address is the key.

That single fact is what the IETF standard for the format calls self-authentication:

".onion names are self-authenticating, in that they are derived from the cryptographic keys used by the server in a client-verifiable manner during connection establishment."

Reaching the address proves you are speaking to whoever holds the matching private key. Nothing issued that key, nothing can revoke it, and nothing outside the math vouches for it. "Ownership" of a .onion name, the standard notes, is derived solely from control of the keypair. There is no company to call and no certificate authority in the middle, which is the property that makes onion services useful and the property that makes a name meaningless as a source of trust.

Why it looks unreadable, and why that is the point

A 56-character string of what looks like random letters and digits is not a design failure; a readable name was never the goal. The label is a hash-derived encoding of the key, not a word chosen by the operator, so it is not meant to be memorable, and RFC 7686 says so directly: the cryptographic label component of a .onion name "is not intended to be human-meaningful."

The same document names the risk that follows from that in its own security considerations: an attacker may be able to find a key that produces an address visually or semantically similar to a real one. That risk is magnified, not reduced, by the fact that .onion names are not human-meaningful in the first place, so nothing about how a name looks helps a reader catch a forgery. The RFC's own mitigation is not "read carefully." It is to rely on bookmarks and other trusted stores rather than re-typing or eyeballing an address from memory. That is the entire reason a signed mirror list exists on a site like this one: it replaces the reader's eye, which cannot catch a two-character swap in a 56-character string, with a signature, which can.

How an address stays reachable

An onion service does not sit waiting at a fixed network location the way an ordinary website does. It publishes a signed descriptor, listing where it can currently be reached, to a small set of relays on the Tor network carrying the HSDir flag. A client wanting the address fetches that descriptor from the same relays before it can connect at all.

Two things make that arrangement change constantly rather than sitting still. The descriptor carries its own lifetime, and services set that field to 180 minutes, so it is republished on a timer well before it would lapse. And the specific relays responsible for holding it rotate on a fixed schedule, a new set roughly once a day, precisely so that no single fixed set of directories can be targeted to remove a service permanently. Reachability, in other words, is a continuously refreshed arrangement between a service and the network, not a static fact about a domain.

Why an address rotates and expires

Onion services have no equivalent of ordinary rate limiting, because hiding the client's address is the entire point of the design, and that leaves an operator with fewer tools against a flood of connection requests than a normal website has. Running several addresses at once, and retiring one under pressure in favour of a fresh one, has long been the blunt answer.

Tor's more targeted answer shipped in version 0.4.8: a proof-of-work challenge that a service can turn on only when it is actually under load. Its designers stated the reason for it plainly in the proposal that led to it:

"If we ever hope to have truly reachable global onion services, we need to make it harder for attackers to overload the service with introduction requests."

The mechanism stays dormant until a service is under stress, then asks arriving connections to solve a puzzle and serves them roughly in order of the effort shown, which raises the cost of a flood without asking legitimate visitors to identify themselves. An address rotating under pressure and a proof-of-work queue kicking in are two responses to the same underlying problem, and neither one means a service is failing; both mean it is being attacked and is coping.

Three reasons a link stops loading

A blank page in the browser looks identical regardless of which of these caused it, which is exactly why the distinction is worth holding onto rather than reaching for the nearest replacement link.

The middle row is the one that catches people out. "It loaded an hour ago" establishes very little, because a retired address keeps answering for a while after it stops being the current one, which is precisely long enough to mislead someone who assumes recency means correctness.

What none of this proves

Every mechanism above governs whether an address resolves. None of it governs whether the operator behind that address is who they claim to be. A second onion address published by the same name is a separate key with no relationship to the first beyond an operator's say-so, and inspecting either address, however carefully, will never settle that on its own.

What settles it is a list of addresses the operator has signed with a key readers can check independently, the method our PGP verification walkthrough sets out step by step. A working link answers one question. A signature answers the other, and it is the only one of the two that has anything to do with trust, which is why every entry in the market directory is paired with one rather than left to speak for itself.

Common questions about onion addresses