How torverify Verifies a .onion Address Before You Connect in 2026

Why torverify says a link is not proof

An onion address is a public key in disguise, which is a strength. Nobody can fake the address of a service whose key they do not hold. But it is also unreadable, so people copy links from wherever is handy. Attackers exploit that by registering look-alike addresses and seeding them into forums, chats, and search results. A matching name, a copied layout, even a green badge, none of it proves anything on its own.

What an address actually encodes

A v3 onion address is derived directly from the service's Ed25519 public key — it is not an assigned name like a clearnet domain, and nobody, including torverify, can reserve or transfer one the way a registrar transfers a domain. That is precisely why torverify's verification model relies on signatures rather than any registration authority: none exists on Tor by design.

Why "it looks right" is the weakest possible check

Visual similarity is the one property an attacker can optimize for cheaply — generating addresses until one happens to look close to genuine costs computing time, nothing more. Every other property on this torverify page's checklist costs an attacker something real: a signature requires the actual private key, a quorum requires compromising multiple independent parties. That's the whole reason "looks right" ranks last, not first, in a real verification routine.

What those 56 characters actually are

To read an onion address well, it helps to know what you are reading. A v3 address is not a random label a registrar handed out — it is a compact encoding of the service's own cryptographic key, which is exactly why nobody can reassign or transfer one. torverify's whole model leans on this fact, so it is worth spelling out in full rather than taking on faith.

The 56 characters you see before .onion are the base32 encoding of exactly 35 raw bytes, laid out in three parts:

Base32 turns those 35 bytes into 56 characters at a fixed rate of 8 characters per 5 bytes, with no padding — which is why a genuine v3 address is always exactly 56 characters, never 55 and never 57. The alphabet is the lowercase letters a–z and the digits 2–7, and nothing else. If a string you were handed contains an uppercase letter, or the digits 0, 1, 8, or 9, it is not a valid onion address at all — you can reject it on sight without checking anything further.

Why the checksum quietly protects you — and where it stops

Because two of the 35 bytes are a checksum derived from the key itself, a random slip — one transposed character, one wrong digit — almost always produces an address whose checksum no longer matches. Tor Browser computes that checksum before it connects, and when it fails it refuses the address outright with an "Invalid onion address" error rather than sending you to whatever key the mistyped string happened to encode. That is real protection, and it is free, but it protects you only against accidents. It does nothing against a deliberate clone: an attacker who grinds out a look-alike address has computed a genuine key for it, so its checksum is valid by construction. The checksum catches your typos; it cannot catch someone else's forgery. Only the signature can.

Why a "vanity" prefix is cheap and a full match is not

The reason phishing addresses so often match the first several characters of a real one is that those leading characters correspond to the start of the public key, and an attacker can generate keypairs in bulk, keeping only the ones whose encoding happens to begin the way they want. Matching a handful of leading characters is a matter of hours on ordinary hardware. Matching the entire 56-character string would mean reproducing the target's exact private key, which is computationally infeasible — the same one-way property that makes the address trustworthy in the first place. This asymmetry is the practical reason torverify's routine below insists you compare the whole string: the part an attacker can cheaply fake is precisely the part most people glance at, and the part they cannot fake is the part most people skip.

torverify's routine, step by step

1. Start from a signed source, not a link. Open a record you already trust, such as torverify's signed source, and read the address there. Do not follow a link someone gave you.
2. Compare the full 56 characters. A v3 onion is 56 characters before .onion. Check the whole string, not the first few letters. One swapped character is a different site.
3. Check the PGP signature. The signed source is signed with a known key. Verify that signature on torverify's PGP tool before you trust the address it covers.
4. Confirm the fingerprint out of band. Match the signing key against a copy you got through a second channel. A signature from an unknown key tells you the file is consistent, not that it is genuine.
5. Copy, do not click. Select the address as text and paste it into Tor Browser yourself.

Why each step has to happen in this order

Skipping ahead defeats the purpose of the steps that come after. Checking a signature before comparing the raw address wastes effort verifying something attached to the wrong string; clicking before copying reintroduces exactly the risk the whole routine exists to avoid. Running them in order is what makes torverify's routine fast in practice, not slower.

torverify's quick checklist

• The address is 56 characters plus .onion.
• It came from a signed source, not a message or a search result.
• The PGP signature over that source verifies against a key you trust.
• The key fingerprint matches a copy from a second channel.
• You copied the string as text rather than clicking a link.

Common mistakes torverify sees when verifying a .onion address

torverify sees the same handful of shortcuts undermine this routine again and again.

Mistake 1: checking the address but skipping torverify's signature step

A matching address with no valid signature is the most common shape a convincing fake takes. Address comparison alone is necessary but not sufficient — see the signature guide for the half this routine only summarizes.

Mistake 2: doing the whole routine from inside the suspect page's own tab

If a page is itself the clone, running "verification" through a tool it links to or a copy-paste flow it controls proves nothing. Do the comparison and signature check using torverify's own pages, opened independently, not through anything the page you're checking provides.

Mistake 3: treating a past verification as still valid

An address confirmed last month is not automatically still correct today. Projects rotate keys; re-run this routine each time you're relying on an address for something that matters, not just the first time.

Worked example: torverify's routine applied

Say a signed source lists this Nexus address. You would read it here, verify the signature, then copy it by hand:

Teaching example only. Always cross-check the record on the Nexus verdict and confirm the signature before you rely on any address.

Walking through why this specific address passes step one

Count it: 56 characters before .onion, no obvious homoglyphs, matching torverify's signed source byte for byte. That clears the string-comparison step. It still requires the signature and fingerprint steps before torverify would call it fully verified — passing step one alone is never the finish line.

Telling an invalid address apart from one that is merely down

Two failures look similar in Tor Browser and mean very different things, and confusing them is how people get talked into a "working mirror" they should have refused. Knowing which one you are looking at tells you whether to re-check the address or simply wait.

"Invalid onion address" is a maths failure, not a network one

If Tor Browser rejects an address before it ever tries to reach the network — typically wording along the lines of an invalid address — the string itself failed the checksum described above. That is not a sign the service is down; it is a sign the address is malformed, usually because a character was dropped, added, or mistyped somewhere in the 56. The fix is never to hunt for a "replacement" address from a stranger — it is to re-copy the correct string from a source you trust and try again.

A checksum-valid address that won't load is a different situation entirely

If the address is accepted and Tor simply cannot reach the service — a timeout, an "Onionsite Not Found," an introduction failure — then the string is well-formed and the problem is on the network or the service side: relay churn, the service being offline, or ordinary maintenance. This is exactly the moment clone operators count on, because a genuine outage feels indistinguishable from a dead link to someone in a hurry. A verdict on torverify does not change because a service is temporarily unreachable; a well-formed address that matches the signed source is still the right address whether or not it happens to answer this minute. Waiting and retrying is the correct response, not swapping in an unverified address someone helpfully offers while the real one is down.

Why "the old one stopped working" is never, by itself, a reason to trust a new address

Put the two failures together and a common phishing script falls apart. "The old link is dead, use this one" is designed to make a routine outage feel like a permanent move, so that you accept a fresh address without running it through the same checks as the original. But neither kind of failure above tells you anything about whether a different address is genuine — that is a separate question answered only by comparing the new string against the signed source and confirming its signature, exactly as if you had never seen the old one.

What torverify's routine does not cover

Verifying that an address is genuine is a narrower claim than verifying that connecting to it is a good idea right now. This torverify routine, deliberately, stops at the address.

It doesn't tell you whether Tor Browser itself is safe to use as configured

A correctly verified address reached through a compromised or misconfigured Tor Browser is not actually safe. Keep Tor Browser updated through the official Tor Project channel, and leave the security slider at a level appropriate for what you're doing — that's a separate, equally important habit this page doesn't cover in depth.

It doesn't tell you anything about what happens after you connect

Escrow disputes, vendor conduct, and operational security choices made by the service itself sit entirely outside what an address check can answer. See torverify's legit markets page for where that line is drawn in more detail.

What about a clearnet mirror instead of an onion address

Some projects torverify tracks also run a clearnet-facing mirror alongside their onion service, usually behind a CDN, and the temptation is to treat whichever one loads faster as equally trustworthy. torverify’s routine above is written for onion addresses specifically because the verification math is different in each case — a clearnet domain rides on the ordinary certificate-authority system, not on a key-derived address, so “the padlock is green” answers a completely different question than “does this address match torverify’s signed source.”

Why torverify treats a clearnet mirror as a separate check entirely

A clearnet domain can be seized, DNS-hijacked, or have its certificate reissued by an attacker who compromises a registrar account — none of which has any onion-address equivalent in torverify’s model. torverify does not currently extend its signed-source coverage to clearnet mirror domains for exactly this reason: the threat model is different enough that folding it into the same signature check would blur what each verdict actually claims.

What to do if a project only gives you a clearnet link

Treat a clearnet-only mirror with more suspicion, not less, than an onion address without a signature. A .onion address is at least cryptographically tied to a specific key — a clearnet domain is tied to whoever currently controls the DNS record and the certificate, which can change hands in ways a visitor cannot easily audit. Where torverify has an onion entry for the same project, prefer it, and treat any clearnet-only claim as a reason to look for the project’s real onion address instead through torverify’s own verify directory.

Why v2 onion addresses no longer exist, and why that matters here

If you find a 16-character ".onion" address referenced anywhere, in an old forum post, an outdated bookmark, or a stale directory, it belongs to the legacy v2 onion service format that Tor formally retired years ago. torverify's routine assumes v3 addresses throughout because v2 is not merely outdated, it is cryptographically obsolete and unroutable on current Tor.

What actually changed between v2 and v3

v2 addresses were 16 characters derived from a truncated SHA-1 hash of the service's key, a scheme with known collision weaknesses that made address-grinding attacks meaningfully cheaper. v3 replaced this with a 56-character address derived directly from an Ed25519 public key, closing that gap and making a targeted collision computationally infeasible with current hardware. Every address torverify tracks is v3, and any 16-character address you encounter today is either a dead relic or evidence someone hasn't updated their materials in a very long time.

What to do if you only have a v2-format address

Treat it as dead, not as something to work around. A v2 address has no live successor by cryptographic definition, meaning there is no "convert this" step, since the underlying key derivation itself changed. Find the project's current v3 address through torverify's verify directory instead of trying to resolve an address format Tor no longer routes.

Tools that make torverify's routine faster, without changing what it checks

The routine above works with nothing but Tor Browser and a way to compare two strings. A few tools make it faster without changing what actually gets verified.

A password manager doubles as an address vault

Storing a confirmed address in an encrypted vault such as KeePassXC, the same way you'd store a password, gives you a copy-pasteable source that is harder to tamper with than a browser bookmark and easier to audit than a plaintext note. It does not replace re-checking against torverify's signed source periodically, but it removes the retyping risk described in step two above.

An isolated operating system reduces what a single mistake costs

Running this whole routine inside Tails or a Qubes OS Tor qube means that even if verification somehow fails and you land on a hostile page, the blast radius of that mistake is contained to a disposable environment rather than your primary system. This doesn't change any step of torverify's routine; it changes how much a single missed check can cost you.

Why torverify recommends tools it doesn't build itself

torverify builds exactly one browser tool, the PGP verifier, and deliberately does not try to build a password manager, an operating system, or a wallet on top of that. Each of the projects named on this page and on torverify's homepage is independently maintained, widely audited, and already trusted well beyond torverify's own scope — recommending them costs torverify nothing and gives a reader working tools instead of a duplicated, less-tested version torverify would have had to build and maintain itself.