Onion Websites Explained: How Tor Hidden Services Stay Hidden

Tor as a network, and onion services as its second half

Most people meet Tor as an anonymity tool for the regular web. Your traffic passes through three volunteer relays, and the website you visit sees the last relay's IP instead of yours. That protects the visitor but not the destination; the site still lives on an ordinary server with a public address.

Onion services extend the same idea to the server side. The site operator runs Tor alongside the web server and configures it to accept connections only through the network. The server builds its own circuits into Tor, and visitors build theirs, and the two meet in the middle. Neither side learns the other's IP address.

The everyday consequence is that an onion site cannot be located by the usual methods. There is no DNS record, no hosting provider to subpoena from the address alone, and no way to ping it. This design is what makes the sites useful to whistleblower platforms and equally attractive to criminals.

Where the .onion address comes from

An onion address is not chosen or registered. It is derived from the service's public cryptographic key. When an operator sets up an onion service, the Tor software generates a key pair; the public key, encoded in base32 with a checksum and version byte, becomes the 56-character address.

This has two useful properties. First, the address is self-authenticating: if you reach a site at a given onion address, you are talking to whoever holds the matching private key, with no certificate authority required. Second, nobody can take an address away or assign a duplicate.

The downside is that addresses are unreadable. Operators who want a recognizable prefix generate millions of keys until one begins with the letters they want, which is why some well-known services have addresses that start with a brand name and then trail into randomness. The random tail is not decoration; it is the cryptographic part you should compare when checking a link.

How a browser finds a server with no address

The connection process happens in a few steps, all of them inside the network:

1. The onion service picks several relays as introduction points and builds circuits to them.
2. It publishes a signed descriptor, listing those introduction points, to a distributed hash table spread across Tor's directory relays. The descriptor is encrypted so only clients that know the address can read it.
3. Your Tor Browser computes where the descriptor should be, fetches it, and learns the introduction points.
4. Your browser picks a relay as a rendezvous point, builds a circuit to it, and sends the service a message through an introduction point saying where to meet.
5. The service builds its own circuit to the rendezvous point, and the two circuits are joined.

Six relays now sit between you and the server, three chosen by each side. That is why onion sites are slower than the regular web, and why the padlock in Tor Browser shows an onion icon: the connection is end-to-end encrypted without any HTTPS certificate.

Why v2 onion addresses stopped working

For years onion addresses were 16 characters long. Those were version 2 services, built on cryptography that had aged badly, including a hash function with known weaknesses and a design that let directory relays learn which addresses existed. The Tor Project deprecated v2 and, after a long warning period, removed support from the software entirely.

The practical result is that every 16-character onion address you find in an old article, forum post or directory is dead. It will not load in a current Tor Browser, and no workaround brings it back. Services that survived migrated to new 56-character v3 addresses, which they announced through their own channels.

This matters when you evaluate a link list. A directory full of short addresses has not been maintained since the deprecation, and the rest of its content is probably stale too. A site that publishes only long addresses and dates its updates is a better sign.

Hosting an onion service is ordinary hosting plus configuration

The phrase "onion web hosting" suggests a specialized industry, and a few providers do market it, but the reality is plainer. Any server that can run the Tor daemon can host an onion service. Operators add a few lines to the Tor configuration pointing at the local web server, restart, and receive an address.

That simplicity is why onion services are used for things far from the dark web stereotype. Individuals host personal pages. Companies publish onion mirrors so users on hostile networks can reach them. Some run internal tools as onion services purely so the server never needs a public port.

The hard part is not the setup but the operational discipline. The web server must not leak its real IP through error pages, headers, misconfigured software or linked resources. Documented takedowns of criminal sites have often traced back to exactly those mistakes rather than to any weakness in Tor itself.

Context from the people who build and study the network

• Tor Project documentation describes onion services as providing location hiding, end-to-end encryption and self-authenticated addresses without certificate authorities. For a visitor this means the onion icon in the browser is the equivalent of a verified HTTPS padlock.
• Tor Project metrics publish estimates of the number of unique onion addresses seen by the network over time, which are the only public figure for how many services exist. The count fluctuates and includes many short-lived and non-web services.
• Academic research on onion service reliability has found that a large fraction of addresses are unreachable at any given moment, which explains why so many links in directories fail. A dead link is often just an offline server, not a scam.
• Court records from operations against illegal onion services frequently describe server location through operational errors such as leaked IPs and login reuse rather than through breaking the protocol. The design holds; humans slip.

What this means for you, and one thing to try

The takeaway is that an onion address is a cryptographic promise, not a location. It guarantees that you are talking to the holder of a key, and it guarantees nothing about who that is or whether the content is safe. Verification of addresses through trusted channels is doing the work that certificates do on the ordinary web.

To see the mechanism first-hand, open Tor Browser, visit a known onion service from the Useful Resources page, and click the onion icon in the address bar. The circuit display shows the relays on your side of the rendezvous, and the padlock explains why the site counts as secure without a certificate.

If you want to go one level deeper, the Tor Project's setup documentation walks through publishing a test onion service from a personal computer in a few configuration lines. Doing it once, even for a page that says hello, makes the abstractions concrete: you will see the key generated, the address derived from it, and the service reachable from Tor Browser with no port opened on your router.

Frequently asked questions