Tor Onion URL: The Journey From Address Bar to Onion Service
Step one: Tor Browser recognises a tor onion url and refuses to use DNS
The first thing that happens when you enter a tor onion url is a decision that ordinary browsers never face. Tor Browser recognises the .onion suffix as special and does not send the name to the domain name system. This is deliberate and is backed by an internet standard reserving .onion so that resolvers should refuse it. If the address were leaked to DNS, the mere act of looking it up would tell your network provider which onion service you were interested in. Instead, the browser hands the address to the Tor client running alongside it. The client decodes the 56 characters into the components described in our article on onion address anatomy: a public key, a checksum and a version byte. It checks the checksum, and if the address was mistyped or malformed it stops here with an error, having sent nothing to the network. The practical lesson is that a tor url which fails immediately, with an error about an invalid address, has failed at this stage. Nothing was looked up. Either the address is corrupted, or it uses the retired 16-character format, or it was never an onion address at all. Conversely, an address that passes this stage has proven only that it is well-formed. Whether a service exists at it, and whose service it is, remains entirely open.
Step two: finding the service without anyone learning which one you want
With a valid address in hand, the Tor client needs to learn how to reach the service, and the design here is the part of the system most people never see. Onion services publish a descriptor, a signed document listing points in the network where the service can be contacted, to a distributed directory maintained by relays. The client has to fetch that descriptor. The subtlety is that the client does not ask for the descriptor by the service's public address. It derives a blinded identifier from the address and the current time period, and asks for that. The directory relays holding the descriptor can serve it without knowing which public address it corresponds to. This is the property that closed the harvesting loophole of the older format, and it is why no directory relay, and no crawler observing them, can build a list of what exists on Tor. For readers the lesson is about failure modes. If the descriptor cannot be found, the service is offline, has changed its address, or never existed. Tor Browser reports this as an unreachable onion site. An onion link sites listing marked as live may still fail here, because the list was compiled at some earlier time. Note also that fetching a descriptor proves nothing about the operator; anyone who holds a private key can publish a descriptor for its address, including the operator of a clone.
Step three: the rendezvous, and why a dark web onion link never reveals a server
The descriptor lists introduction points, relays the service has chosen to accept contact through. The client picks a relay of its own to act as a rendezvous point, then sends a message through an introduction point asking the service to meet it there. The service, if it is online and willing, builds its own circuit to the rendezvous point. Neither party ever learns the other's network location. Traffic flows through the rendezvous, encrypted end to end between client and service. This is why a dark web onion link does not lead to a server in the way a clearnet address does. There is no IP address to discover, no hosting company to query, no geographic location to infer. The service is wherever the private key is, and it can move without changing its address, because the address is the key and not the place. Two lessons follow. First, the same property that protects legitimate operators protects clone operators equally; you cannot tell where a service is hosted, so you cannot use hosting as a signal of legitimacy. Second, the multi-hop construction is why onion services load more slowly than clearnet sites through Tor. The client's circuit and the service's circuit each have several hops, and the rendezvous joins them. A slow page is a property of the design, not a warning sign, though a page that was fast yesterday and hangs today may indicate the service is struggling or has moved.
Step four: encryption without certificates, and what the onion icon really means
When the rendezvous completes, traffic is encrypted between your browser and the service using keys derived during the handshake. No certificate authority was involved. The service proved that it holds the private key matching the address, because the handshake would fail otherwise, and that is the entire guarantee. Tor Browser reflects this with an onion icon in the address bar in place of the padlock used for certificate-backed clearnet sites. It is essential to read the icon correctly. It means: this connection is inside Tor, end-to-end encrypted, to whoever holds the private key for this address. It does not mean: this is the service you were looking for. If the address you entered belonged to a clone, the clone holds a private key, the handshake succeeds, and the icon appears exactly as it would for the genuine service. A scenario: a reader opens an onion website link from a forum post, sees the onion icon, and treats it as a green light. They have confirmed that the link was well-formed, that a descriptor exists, that a service answered, and that it holds the key for that address. Every one of those would be true of a phishing clone. The icon confirms the mechanism worked. It has nothing to say about the identity behind it, and treating it as proof of identity is the single most common misreading on this network.
What the journey tells you about any onion website link you are given
Walking through the connection clarifies exactly which questions an onion website link can answer on its own and which it cannot. The address itself can tell you whether it is well-formed and current. Attempting the connection can tell you whether a descriptor is published, meaning some service currently claims the address, and whether that service is answering. The completed connection can tell you that the service holds the private key. That is the full list. What the link cannot tell you, at any stage, is who holds that key. Not the browser, not the icon, not the speed of loading, not the appearance of the page, not the number of places the address has been posted. Identity has to be established through a channel outside the connection: the operator's clearnet website, a PGP-signed announcement whose key has history, or an Onion-Location prompt delivered by a verified clearnet site. Our Useful Resources page walks through checking a signature. - Well-formed address: proves the address could work. - Descriptor found: proves someone currently operates a service there. - Handshake succeeds, icon appears: proves they hold the key. - Operator's channel confirms the address: proves whose key it is. Only the last line establishes identity, and it is the only one that happens outside Tor Browser. Every safe habit on this network is a way of making sure that line is present before anything sensitive occurs.
Common problems opening a tor browser url, and what they mean
Because the journey has distinct stages, failures at each stage look different, and reading them correctly saves time and prevents bad workarounds. 1. Invalid onion address error, immediately. Failed at stage one. The address is malformed, corrupted in copying, or in the retired format. Re-copy from the source, and if it is 16 characters, discard it. 2. Onion site unreachable, after a wait. Failed at stage two or three. No descriptor, or the service did not come to the rendezvous. It is offline, moved or gone. Check the operator's channel for status or a new address; do not accept a replacement from a directory. 3. Very slow loading. Normal for onion services, especially at busy times. Not a signal of anything by itself. 4. Page loads but looks wrong, asks for unusual permissions or demands JavaScript. The connection succeeded; the question is whose service you reached. Return to the operator's channel and compare the full address. 5. The address works one day and not the next. Services go offline and return. Wait, then check the operator's channel. Never search for a working alternative in the meantime; that is the moment clones are waiting for. A scenario: a tor browser url from a bookmark starts failing at stage two. The reader resists the urge to search for a new one, checks the project's clearnet site, and finds a signed notice announcing a new address after an infrastructure move. The old bookmark is replaced from the notice. The failure was information, and the operator's channel turned it into a safe update.
The mechanism is trustworthy, the identity is your job
A tor onion url triggers a sequence that is genuinely impressive: no DNS leak, a blinded directory lookup, a rendezvous that hides both parties' locations, and encryption tied to the address itself with no certificate authority in the loop. Every stage does what it promises. What none of them promises is that the key at the far end belongs to the person or project you had in mind, and the onion icon, which is the only visible sign of the whole process, is routinely misread as saying exactly that. Once the journey is understood, the correct division of labour is obvious. The network handles reachability and encryption. You handle identity, through operators' accountable channels, before you type or download anything. The lesson generalises to every link onion websites offer: the connection can be perfect and the destination still wrong. One step to take today: open a verified onion bookmark in Tor Browser and watch the address bar as it loads. Notice the pause while the descriptor is fetched and the rendezvous completes, then notice the onion icon appear. Say to yourself what it actually proves: encrypted, inside Tor, to the holder of this key. Then recall how you know whose key it is. If you cannot answer that last part, you have found the bookmark to verify next.
Frequently asked questions
does tor browser use dns to open an onion address?
No. Tor Browser recognises the .onion suffix and hands the address to the Tor client, which decodes the embedded public key and looks up a service descriptor through a blinded identifier. The name never reaches ordinary DNS, so your network provider cannot see which onion service you visited.
what does the onion icon in tor browser actually mean?
That the connection is inside Tor, encrypted end to end, to whoever holds the private key for the address you entered. It does not confirm who that is. A phishing clone holds its own key and shows the same icon.
why do onion sites load slowly?
The client and the service each build multi-hop circuits that meet at a rendezvous relay, so traffic crosses several relays in each direction. Slowness is a property of the design, not a warning sign, though a sudden change from fast to unreachable may indicate the service moved or is struggling.
what does onion site unreachable mean?
No descriptor was found for the address, or the service did not respond at the rendezvous. It is offline, has changed its address, or never existed. Check the operator's own channel for status rather than accepting a replacement address from a directory.
how can i tell who runs an onion service?
Not from the connection itself. Identity must be established through a channel outside Tor Browser: the operator's clearnet website, a PGP-signed announcement, or an Onion-Location prompt from a verified clearnet site. Compare the full address and bookmark only what matches.