The first time you see an onion address it looks like a mistake, a smear of letters and numbers with no vowels to hold onto. The instinct is to treat it as a code you copy carefully and forget. It rewards a second look. That string is doing something an ordinary web address cannot: it carries its own proof of identity, so the thing you type is also the thing that lets your browser confirm it reached the right service. Once that clicks, the length stops being an annoyance and starts being the point.
What an onion address is
On the ordinary web, a name like a shop's address is a label. It gets looked up in a global directory, which returns the number of the machine to connect to, and a separate certificate tries to prove that machine is who it claims. An onion address folds those steps together. It is not looked up in a public directory at all, and it does not lean on a certificate authority. The address is derived directly from the service's cryptographic key, so it is less like a name and more like a fingerprint that also happens to work as an address.
The anatomy of the string
A current onion address has a fixed structure, even though it looks random. The bulk of it is the encoded public key. A short piece near the end is a checksum, a self-check that lets software reject an address that was mistyped. A single character records which version of the design it is. All of that is packed into 56 characters drawn from a limited alphabet, the lowercase letters and the digits 2 through 7, which is why you never see a 0, a 1, an 8 or a 9 in one.
Counting the bytes: why fifty-six, exactly
The length of an onion address is not a design preference or a round number somebody liked. It falls out of arithmetic, and following that arithmetic once is the quickest way to stop thinking of the string as arbitrary.
Three pieces go in, and they have fixed sizes. The public key is thirty-two bytes. The checksum is two bytes. The version marker is one byte, currently holding the value three. Add them up and you have thirty-five bytes, always, for every onion address that has ever been valid under the current design.
Now the encoding. Thirty-five bytes is two hundred and eighty bits. Base32 — the scheme that produces those lowercase letters and digits — represents exactly five bits per character. Two hundred and eighty divided by five is fifty-six, with nothing left over. That clean division is why an onion address is fifty-six characters and why you will never see the padding = character that base32 uses when the input does not divide evenly. The format was chosen so that it would not.
The practical value of a fixed length
Because the length is structural rather than conventional, it is a check you can apply instantly and without any tools. Fifty-five characters is not a slightly-wrong address; it is not an address. Fifty-seven is not an address. A string that ends in .onion but has some other length in front of it is either a mistranscription or a different thing entirely wearing the suffix, and either way there is nothing to reason about. Counting is a weak check, but it is free, and it is the only one that costs you nothing at all.
What the two checksum bytes are for, and what they are not
The checksum is derived from the key it accompanies: software recomputes it from the public key and the version byte and compares. If they disagree, the string was damaged in transit or in transcription, and clients reject it before any connection is attempted. This is genuinely useful and genuinely narrow. Two bytes is a small amount of protection against random damage, and it is no protection at all against a deliberate substitution — because an attacker does not damage an address, they hand you a different one, complete with its own perfectly valid checksum computed from their own key. A checksum answers "was this string mangled". Nothing in the address itself answers "is this the service I meant", which is why verifying an address against a signed source remains a separate job the format cannot do for you.
Why it is a public key, not a name
This is the heart of it. Because the address is built from the service's public key, connecting to it is also a challenge. Your browser can ask the service to prove it holds the matching secret key, and only the real operator can answer. A name looked up in a directory has no such property, which is why the ordinary web needs certificates bolted on top. An onion address needs nothing bolted on, because identity was baked into the address from the start.
torhaven safety note
This is the good news hidden in that ugly string. If you have the right address, in full, you are talking to the right service, full stop. There is no separate certificate to check and no authority whose word you have to take. The entire weight of trust rests on getting all 56 characters right, which is a burden you can actually meet.
What self-authenticating means for you
Cryptographers call an address like this self-authenticating, which sounds abstract until you see the practical effect. It means the danger is not that someone forges a valid address, because they cannot. The danger is only that they get you to use a different valid address, one they own, that looks close enough to the real one to pass a glance. The attack is never on the maths. It is always on your attention.
How your client finds a service with no directory to look in
A reasonable question follows from everything above. If the address is a key rather than a name, and there is no lookup table anywhere translating one to the other, how does your browser find the machine? The answer is one of the more elegant parts of the design, and knowing it explains several things that otherwise look like bugs.
- The service picks a few relays to be its introduction points. It builds circuits out to them and asks them to hold the door. Those relays now know they are fronting for some service, but they do not know where it is, because the service reached them through a circuit like any other.
- It publishes a descriptor saying where those doors are. The descriptor is signed by the key that the address encodes, which means nobody can substitute a forged one; a client that has the address can check the signature against it directly.
- The descriptor is filed under a blinded version of the key, not the address. This is the clever part. The service's identity key is combined with the current time period to derive a different key, and it is that derived value which decides where the descriptor is stored and how it is labelled. The relays holding it therefore never see the onion address itself, cannot work it out from what they hold, and cannot read the useful contents, which are encrypted to something only a party who already knows the address can derive.
- The filing location moves on its own. Because the blinded key depends on the time period, the same service lands in a different place in the directory as time passes. A relay that happens to hold a descriptor today has no way to keep watching that service tomorrow, which is what stops the directory from becoming a census of every onion service in existence.
- Your client derives the same value from the address you typed. It works out which relays should be holding the descriptor for this period, fetches it, decrypts it, verifies the signature, and now knows the introduction points.
- Your client chooses a rendezvous point and invents a one-time secret. The rendezvous point is just another relay, picked by you, told nothing except to expect a second connection carrying a matching secret.
- Your client sends an introduction message through one of the doors. It says, in effect: meet me at this relay, and here is the secret that proves it was me who asked.
- The service builds its own circuit to your rendezvous point. The two circuits are joined there and the conversation begins.
Count the relays in the finished path and you get six: three chosen by you, three chosen by the service. Neither end learns the other's location, because neither end ever made a direct connection. The rendezvous point in the middle carries the traffic while knowing neither party, and every one of those hops is encrypted, which is why an onion connection needs no certificate authority and never touches an exit relay.
Why the first connection to an onion is slow, then normal
All of the above happens before the first byte of the page arrives. Fetching a descriptor, reaching an introduction point and establishing a rendezvous are several round trips through several circuits, and on a slow or congested path they add up to a noticeably long pause. Once the rendezvous is established, though, the connection behaves like any other Tor circuit. A site that takes many seconds to open and then feels ordinary is not misconfigured; you watched the introduction happen.
Why "onion site not found" rarely means what people assume
When a client cannot reach an onion service, the usual cause is that no current descriptor could be fetched — because the service is offline, because its descriptor has not been republished for this time period, or because the relays that should be holding it are unreachable from your circuits. It very rarely means the address is wrong, since a wrong address fails at a different stage and a malformed one fails immediately. Retrying after a short wait, or building a fresh circuit, resolves more of these than any amount of editing the address will.
Services that will not answer strangers at all
The design has an optional extra layer worth knowing about, because you may run into it and mistake it for a broken site. A service can require that clients hold a key of their own before the descriptor can be decrypted. Without it a visitor gets nothing usable even with the correct, complete address in hand, and the service is effectively invisible to everyone who was not given access deliberately. This is a feature, used by private services that want to exist without being enumerable, and it is why "I have the right address and it still will not load" is occasionally the intended behaviour rather than a fault.
Why an onion address cannot be bought, renewed, or taken away
Everything about how the address is created has consequences that feel strange coming from the ordinary web, and most of them cut in both directions at once.
There is no registrar, because there is nothing to register. You generate a key pair and the address is whatever comes out; no authority is consulted and none could refuse. There is no renewal, no expiry and no annual bill, so an address does not lapse through inattention and cannot be lost by forgetting to pay for it. There is also no registry that could be ordered to hand an address over, which is the property the whole design exists to provide.
The same facts read differently from the other side. Because nobody assigns addresses, nobody can reassign one either — there is no dispute process, no arbitration, and no way to recover an address whose secret key someone else has copied. And because the address is the key, control of the key is the whole of control: an operator who loses their key has permanently lost that address, with no appeal and no path back, which is the main reason services rotate addresses far less often than security advice might suggest they should.
The uncomfortable corner of this is worth stating plainly rather than leaving implied. If the machine holding a service's secret key falls into someone else's hands — through seizure, through a break-in, through an operator being compelled — then the address keeps resolving, the descriptor keeps being signed correctly, and every cryptographic check a visitor can run keeps passing, while a different party answers on the other end. No property of the address detects that, because from the maths' point of view nothing has changed. It is the clearest illustration of the boundary this whole guide keeps returning to: the address proves which key is answering, and it never claims to prove who is holding it.
Why old addresses were shorter
You may still see references to 16-character onion addresses. Those belonged to an older version of the design that has since been retired, because its shorter keys were too weak to trust and its addresses were easier to grind look-alikes for. The current version uses stronger keys, which is exactly why the address grew to 56 characters. If something offers you a short onion address today, treat that as a sign it is out of date at best.
| Format | Length | Status |
|---|---|---|
| Older design | 16 characters | Retired, weaker keys, do not trust |
| Current design | 56 characters | In use, stronger keys, self-authenticating |
How look-alikes try to fool you
Since the maths cannot be beaten, attackers work on the string. They generate enormous numbers of keys until they find one whose address happens to start with the same handful of characters as a target, then plant it where you might copy it in a hurry. To a quick glance it reads as the real address. It is not. A single different character anywhere means a different key and a different owner, which is the whole reason the routine is to compare the entire string.
torhaven warning
Never judge an onion address by its opening characters. Matching prefixes is exactly what a look-alike is built to do, and it is cheap to do for the first few. Matching all 56 is not something an attacker can fake, so the comparison that protects you is the one that runs to the end.
Here is the shape of a full address, shown as text so you can see how much of it a real comparison covers:
torhaven verification check
nexusbomklgyvipzr5p4nfluezdsjntzksni4wsqf63kpv2ge4bqnhyd.onionTeaching example only. Read every character against a signed copy, because a fake that shares the first few is the whole trick. Cross-check the canonical list on torindex and confirm the signature on torverify before you rely on it.
Vanity addresses: not a shortcut around verification
Some operators generate keys for weeks or months to land on an address containing a memorable word or short phrase near the start — a "vanity" onion address. This is real and does not make the address any less authentic; the underlying key pair is generated the same honest way, just filtered for a cosmetic prefix. It does not, however, change the verification routine at all: a vanity prefix is exactly the part a look-alike copies most easily, so the full 56-character comparison still applies without exception.
Why copy-paste beats retyping every time
Retyping a 56-character string by hand introduces exactly the kind of single-character slip a look-alike relies on, and autocorrect or predictive text on a phone keyboard makes it worse. Copy the address as a block from a source you have already verified, paste it without editing, and let the length itself work in your favor — a string too long to comfortably memorize is also too long to comfortably mistype without noticing, provided you never retype it from memory in the first place.
What happens to an onion address over its lifetime
An onion address is not permanent by design — understanding what causes one to change helps separate a routine rotation from a warning sign.
Planned rotation
Operators sometimes retire an onion address and publish a new one as routine hygiene, unconnected to any incident — reducing the amount of time any single key pair has been exposed is a reasonable precaution on its own. A planned rotation is normally announced through the same signed channel the operator already uses, so the new address inherits trust from that signature rather than needing to be trusted from scratch.
Rotation after a suspected compromise
If an operator suspects a private key has been exposed, retiring the associated onion address immediately is the correct response — the address is derived from that key, so a compromised key means the address itself can no longer be trusted regardless of how long it worked correctly before. This is one reason a sudden, unannounced address change deserves more scrutiny than a routine one: it may be the visible trace of an incident the operator has not fully explained yet.
Abandonment
An onion address with no operator maintaining it simply stops resolving over time as the underlying server goes offline — no dramatic event, just neglect. This is different from a seizure, which typically replaces the address with a law-enforcement banner rather than making it silently unreachable.
Tools that can help, and their limits
Password managers that store verified addresses
Some password managers can store a verified onion address as a secure note, giving you copy-paste access without re-typing. This helps with the mistyping risk but does nothing for verification itself — a wrong address saved once stays wrong every time you paste it, so verify before you save, not after.
Browser bookmarks
A bookmark is convenient but carries the same risk as any saved copy: it reflects the address at the moment you saved it, not necessarily the current one. Treat a bookmarked onion address as a starting point for re-verification, not as a substitute for it.
Common torhaven questions
Why are onion addresses so hard to read?
Because they are a public key written out, not a chosen name. The randomness is the security. A memorable address would mean a weaker key, which is a trade the design refuses to make.
Can two services share an onion address?
No. The address is derived from a unique key pair, so it belongs to whoever holds the matching secret key. Two services cannot own the same address any more than two people can hold the same secret.
Do I still need to verify if the address is self-proving?
Yes, because the proof only confirms you reached the owner of that exact address. It cannot tell you whether that address is the one you meant, which is why you check it against a signed source.
Is there a padlock for onion sites?
There is no certificate padlock to earn, because connections to onion services are encrypted by default and the address itself carries the identity. The verified address is the proof, not an icon.
Why is an onion address exactly 56 characters?
Because of arithmetic rather than convention. The address encodes thirty-two bytes of public key, two bytes of checksum and one version byte — thirty-five bytes, or two hundred and eighty bits. Base32 writes five bits per character, and two hundred and eighty divides by five exactly, giving fifty-six characters with no padding left over. Any other length is not a slightly wrong address; it is not an address.
Can I buy a shorter or more memorable onion address?
No, because there is nobody to buy it from. Addresses are generated, not assigned, and there is no registrar, no fee and no renewal. Services with a readable prefix produced it by generating enormous numbers of keys until one happened to start with the characters they wanted — and the rest of the address is still unchosen randomness.
Does an onion address expire?
Not by itself. There is no registration to lapse and no bill to forget. An address stops working when its operator stops running the service or loses the secret key, and it can be given up voluntarily, but nothing external takes it away on a schedule.
If a service's server is seized, does its onion address stop working?
Not necessarily, and this is the limit worth understanding. The address is tied to a key, not to a party. If the key is obtained along with the machine, the address keeps resolving and every cryptographic check a visitor runs keeps passing while somebody else answers. Nothing in the address can detect that, because from the format's point of view nothing has changed.
Why torhaven treats the address as its own topic
Most Tor writeups fold "what is an onion address" into a single paragraph inside a bigger install guide. torhaven splits it into its own page because the address is the one thing every later torhaven guide depends on: the deposit-verification torhaven guide, the PGP torhaven guide, and the Torzon profile all assume you already understand why the string is self-authenticating, not just that it is long.
What torhaven builds on top of this torhaven page
Once this torhaven guide's core idea lands — that the address is a public key, not a name — the rest of torhaven's market-safety material stops being a list of rules to memorize and starts being one consequence applied repeatedly: compare the whole string, every time, because the whole string is the proof. torhaven's PGP guide extends this into who can vouch for a given address before you ever compare it yourself.
Reading this torhaven page out of order
If you landed here directly from a search result rather than from torhaven's guide library, that is fine — this torhaven page stands on its own. But if a term like "signed source" or "self-authenticating" feels unexplained, torhaven's what is Tor guide is the one this torhaven page assumes you already read.