August 18, 2026
Updated: August 18, 2026
Why a .onion address is a public key rather than a name, how Tor finds a service without DNS, why link directories rot, and how to verify an onion link is genuine.
Abdalla Mohamed
Onion links are the addresses of Tor onion services, the sites that end in .onion and load only inside the Tor network. They look like random strings for a precise reason: a modern .onion link is not a name at all, but a cryptographic public key encoded as text. That single fact explains why the addresses are 56 characters long, why there is no DNS or certificate authority behind them, why onion directories fill with dead links, and how to tell whether a listed onion site is genuine. This is a technical explainer, so it lists no live links.
Updated: August 2026. Covers v3 onion services (the 56-character format); the old 16-character v2 addresses were retired in 2021 and no longer resolve.
An onion site is a service that is reachable only through the Tor network, and its .onion link is the address you use to reach it. Unlike a normal website, an onion service is not published in the public Domain Name System, has no registered domain, and cannot be opened in an ordinary browser. It lives entirely inside Tor, which is what gives both the visitor and the operator their anonymity. The .onion link, then, is not a domain name pointing at a server; it is a self-contained identifier derived from the service's own encryption key.
That difference is the whole story of this article. Because the link is a key rather than a name, everything downstream behaves differently from the clearnet: discovery, trust, and durability all work in unfamiliar ways. To reach any of these sites you first need the Tor browser, and it helps to understand where onion sites sit in the wider picture of the deep web versus the dark web.
The reason an onion link looks like a jumble of letters and numbers is that it is a public key wearing a costume. On the clearnet, a domain name is a human-friendly label that DNS translates into an IP address. On Tor there is no such translation layer, so the address has to carry the cryptographic identity of the service directly. Encode a public key as text and you get exactly the kind of long, random-looking string that every real onion link is.
Current onion services use the version 3 format, which is always 56 characters followed by .onion, drawn only from the letters a to z and the digits 2 to 7. Those 56 characters are the base32 encoding of three concatenated pieces: the service's 32-byte ed25519 public key, a 2-byte checksum derived from that key, and a 1-byte version number. Written as a formula it is base32(public key + checksum + version), which comes to 35 bytes and encodes to 56 characters. An illustrative address looks like xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxd.onion, though a real one is never something you should trust from a page like this.
| Feature | v2 (retired) | v3 (current) |
|---|---|---|
| Length | 16 characters | 56 characters |
| Underlying key | RSA-1024, 80-bit hash | Full ed25519 public key |
| Status | Deprecated in 2021, no longer resolves | The only working format |
| Checksum | None | Yes, 2 bytes |
Because the address contains the full public key, it authenticates itself. When your Tor client connects to an onion link, the service must prove it holds the matching private key, and only the real operator can. This is why onion services need no certificate authority to prove identity: the address and the identity are the same thing. It also means a checksum can catch a typo before you ever connect, since a mistyped address simply fails its own integrity check rather than silently loading the wrong site.
The jump from 16 to 56 characters was not cosmetic. The old v2 format published only an 80-bit truncated SHA-1 hash of a weak RSA-1024 key, short enough that researchers demonstrated harvesting and impersonating addresses at scale. Version 3 publishes the full ed25519 public key, so there is nothing to truncate and no shortcut to forging a matching address. The blinded-key design also stops the directory relays from logging which onion services exist, closing a privacy leak that v2 left open. The longer address is the visible cost of closing both of those holes, and it is why every current onion link is exactly 56 characters.
Laying the two systems side by side makes the practical consequences obvious. Almost every difference traces back to the same root: a clearnet domain is a rented name in a central registry, while an onion link is a self-owned key with no registry at all. That trade buys anonymity and self-authentication at the cost of durability and human readability.
| Property | Clearnet domain | Onion link |
|---|---|---|
| Naming | Human-readable, via DNS | Random base32, derived from a key |
| Registry | Central registrars | None; the key is the address |
| Identity proof | Certificate authority (TLS) | Self-authenticating by design |
| Renewal | Periodic registration | None; permanent but fragile |
| Recovery if lost | Re-register the name | Impossible; the address is gone |
| Redirects | Supported | None |
Read down the onion column and the behavior of the whole ecosystem falls out of it. No registry means no authority to keep directories accurate, no renewal means abandoned services simply die, and no recovery means a lost key erases an address permanently. The strengths and the fragility come from the same design choice.
Without DNS, finding an onion service is a cryptographic lookup rather than a name resolution. The process is invisible to the user but worth understanding, because it explains both the privacy of the system and why a link either works perfectly or not at all. There is no partial success and no forwarding.
Nothing in this chain touches DNS or a public registry. The address itself is the lookup key, which is elegant for privacy but has a hard consequence: if the key is lost or the descriptor stops being published, the site is simply gone.
Anyone who has used a dark web link list knows that most entries are dead. This is not carelessness; it is built into how onion addresses work, and understanding it is the best defense against trusting a stale directory. Several forces push onion links toward decay far faster than clearnet domains.
Because a directory is only a hand-edited snapshot with no registrar keeping it current, these dead links and their many mirrors accumulate quickly. That churn is also why so many phishing clones thrive, a problem we cover in depth in our explainer on the Hidden Wiki.
Because links rot and directories go stale, automated onion search engines have largely displaced static lists for anyone doing real research. The difference matters: a crawler re-checks whether a site still responds and can filter what it indexes, while a directory just reproduces whatever its editor last pasted in. This is the practical answer to the common searches for an onion search engine.
| Tool type | Examples | How it behaves |
|---|---|---|
| Onion search engine | Ahmia, Torch, OnionLand | Crawls onion sites, re-checks liveness; Ahmia also filters abusive content |
| Static link directory | Hidden Wiki-style pages | Hand-edited snapshot; rots fast and is heavily cloned |
Ahmia is the notable one for safety, because it filters out known abusive material and is even useful defensively, letting an organization search for its own name or data across indexed onion pages. Our roundup of dark web search engines compares the options in more detail. Note that even a search engine returns unpredictable destinations, so the discovery tool does not remove the need to verify what you find.
This is where the "keys, not names" idea pays off practically. Self-authentication guarantees that connecting to a given address reaches the holder of that key, but it only protects you if the address you started with is the correct one. Since you cannot tell a genuine address from a lookalike by reading it, verification has to come from outside the link itself.
.onion and bind it to a verified legal entity; certificate authorities such as DigiCert issue them.The takeaway is blunt: a link found in a directory, a forum, or a comment is unverified by default, and no amount of staring at it will change that. Verification is an act of cross-referencing a trusted channel, not of inspecting the string.
Not every onion service is shady; many mainstream organizations run one to give censored or privacy-conscious users a safer path in. Understanding the legitimate deployment tools also clarifies why some onion addresses are readable and others are pure noise. There are three common pieces.
The scale of all this is tracked publicly by Tor Metrics, which measures the number of onion services and the traffic they carry without ever exposing the addresses themselves. It is the authoritative source if you want real figures rather than the inflated counts directories like to advertise.
The same properties that make onion addresses trustworthy in theory make them dangerous in practice for the unprepared. An attacker cannot forge a self-authenticating address, but they do not need to: they only need you to start with the wrong one. That is the entire basis of the onion phishing economy, where lookalike addresses and cloned directory pages funnel newcomers to credential-stealing and wallet-draining sites.
This is why, on a security company's site, you will not find a working onion link list here. We cannot verify third-party addresses as safe, many are outright phishing clones, and the ones that are genuine change too often to vouch for. The useful skill is the verification discipline above, not a list that will be stale or malicious by next month. For organizations, the practical concern is not browsing onion sites at all but knowing when company data appears on them, which is the job of dedicated dark web monitoring, and the wider reality of Tor anonymity is covered in how anonymous the dark web really is.
An onion link is the .onion address of a Tor onion service, a site reachable only inside the Tor network. It is not a domain name but a base32 encoding of the service's public key, which is why it looks random. The link authenticates the service directly, without DNS or a certificate authority.
Because the address is a cryptographic key, not a name. A version 3 onion address encodes a 32-byte ed25519 public key plus a checksum and version byte into 56 base32 characters. There is no DNS to translate a friendly name, so the key itself has to serve as the address.
An onion search engine, such as Ahmia, Torch, or OnionLand, crawls .onion sites and indexes them so you can search the dark web the way you would the clearnet. Unlike a static link directory, a search engine re-checks whether sites are still live, and some, like Ahmia, filter out abusive content.
Onion services are ephemeral and leave no forwarding address. Operators can shut them down at any time, a lost key makes an address unrecoverable, and there are no redirects. The 2021 retirement of the old v2 format also broke every 16-character address at once, which is why old link lists are mostly dead.
You cannot tell by looking, since real and fake addresses are equally random. Obtain the address from a trusted channel instead: the organization's own HTTPS site, an Onion-Location header, or an extended-validation certificate that names the onion. A directory listing or forum link is unverified by default.
No. Onion services do not use the Domain Name System. The address is derived directly from the service's key, and your Tor client finds the service by looking up a signed descriptor on hidden service directory relays. This is why there is no registrar, no renewal, and no human-readable naming.
Those were version 2 addresses, based on weaker RSA-1024 cryptography. Tor deprecated them in 2021, and they stopped resolving when the network moved to Tor 0.4.6 that October. Every onion service now uses the stronger 56-character version 3 format, so any 16-character link you find is dead.
Not for identity, because the address already authenticates the service cryptographically. Some organizations still obtain TLS certificates that name their .onion to bind it to a verified legal entity and to reassure visitors, but a certificate is optional on Tor in a way it never is on the clearnet.
No. Each address is derived from a unique ed25519 key pair, and the key space is far too large for a practical collision. If two services genuinely showed the same full 56-character address, they would be using the same key, which means the same operator. Impersonators only ever match a prefix, never the entire string.
A vanity address is one whose opening characters spell a chosen word, produced by generating key pairs until the resulting address starts with that prefix. Legitimate sites use it for a recognizable start, but attackers use the same technique to fake a familiar-looking prefix, so a matching prefix alone never proves an address is authentic.
Onion links make far more sense once you stop reading them as names and start seeing them as keys. That reframing explains the length, the randomness, the absence of DNS and certificate authorities, the constant link rot, and the impossibility of judging authenticity by sight. The practical lesson is to trust the source of an address, never the string itself, and to treat every directory listing as unverified. For organizations, the question that matters is not how to browse onion sites but whether your data is already on one, and DeepStrike's security testing and monitoring is built to answer it without anyone chasing a link.
Stay secure with DeepStrike penetration testing services. Reach out for a quote or customized technical proposal today
Contact Us