How to verify an onion address before you trust it

an onion address looks like random noise, and that is exactly the problem. when every address is a 56-character scramble, your eye cannot tell the real one from a fake, and phishers know it. the good news is that v3 addresses carry their own tamper-evident math: the last few characters are a checksum over the rest, and the whole thing is derived from a cryptographic key. once you understand what the string is made of, verifying it stops being guesswork and becomes a checklist you can run in under a minute.

why an onion address cannot be compared to a domain name

with a normal website you lean on names and authorities: the name system resolves example.com, and certificate authorities vouch for who owns it. none of that exists for onion services. there is no registry, no authority and no way to buy or reclaim an address. instead, the address itself encodes the service's public key, so control of the address is identical to possession of a private key.

that has two consequences. first, nobody can impersonate an address without stealing its key material. second, anybody can generate a brand-new address that looks equally legitimate, which is precisely what phishing kits do: they mint fresh onions at scale and dress them up with cloned pages. the defense is never "this looks right" - it is "this exact string matches what the operator published, signed, somewhere i trust."

the anatomy of a v3 address

every version 3 onion address follows the same recipe defined in the tor rendezvous spec version 3:

• take the ed25519 public key of the service (32 bytes)
• compute a checksum: sha3-256 over the constant string ".onion checksum", the public key, and a single version byte 0x03
• keep the first two bytes of that hash as the checksum field
• append version byte 0x03, encode everything in base32, and add the .onion suffix

from the outside you see the result: exactly 56 characters drawn from the base32 alphabet - lowercase letters a-z and digits 2 through 7 - followed by .onion. no uppercase, no zeros, no ones, no l, no 0 or 1 anywhere, because base32 excludes the most confusable characters. that alone kills a lot of classic lookalike tricks before you even reach the checksum.

step-by-step: verifying an address

1. start at the source, not the destination. decide in advance whose announcement counts as official: the project's own clearnet site, its pgp-signed statement, or a directory you have trusted for years. an address pasted into a chat by a stranger is not a source.
2. check the format. confirm the string is 62 characters total including .onion, uses only a-z and 2-7, and has no spaces or line-break damage from wherever you copied it. our onion address validator does all three checks plus the v3 checksum computation entirely in your browser.
3. cross-check the checksum. the last characters of a v3 address must match the hash of everything before them. a scammer who changes even one character produces an address whose checksum fails - unless they went further and computed a whole new key pair, which brings you back to step one: provenance beats format.
4. verify the announcement itself. serious operators publish their onion addresses in messages signed with pgp. import their public key once, verify the fingerprint, and from then on every new or moved address can be checked with a signature instead of trust. see our guide to verifying pgp signatures for the full procedure.
5. probe availability separately. a well-formed address can still be offline, and an online impostor is more dangerous than a dead one. run the target through our onion status checker, which connects over tor and reports whether the service actually responds.

where official addresses come from

for software and infrastructure projects the chain is usually clean: the tor project publishes its own services on torproject.org over https, signs release announcements with gnupg keys fingerprinted on the same site, and keeps mirror lists under version control. for markets and other commercial onion services the chain is murkier, which is why fake mirror lists outnumber real ones - we documented that economics in detail when covering official link lists and mirror wars.

practical hierarchy of trust, best first:

• an address published on the operator's own long-lived https site
• an address inside a pgp-signed message from a key whose fingerprint you verified earlier
• an address listed consistently across several independent, reputable directories
• an address someone sent you, with no way to check who wrote it first

notice that search results and paid promotions sit nowhere on this list. advertising slots are sold, not earned, and seo-poisoned pages exist purely to hand you a phishing onion at the moment you search for a market's name.

what the checksum protects - and what it does not

the v3 checksum is a integrity feature, not an identity feature. it proves the string was not mangled in transit or altered after generation, because any edit breaks the hash relationship. it says nothing about who generated the key. an attacker can trivially create a valid-looking address with a working checksum; what they cannot do is produce your vendor's specific address.

this distinction matters most around deposits. clipboard hijackers swap addresses in transit, and fake seizure banners try to rush you toward "verification" mirrors. slow down at the moment money moves: re-read the address character group by character group, or paste both copies into our text diff tool to highlight a single changed character instantly.

common failure patterns

most verification failures fall into four buckets:

• copy damage - chat apps wrap long strings, mail clients insert soft hyphens, pdfs add line breaks. always validate after copying, not before.
• source confusion - trusting the first result rather than a pre-decided official source.
• signature theater - importing whatever key the phishing page helpfully provides, then "successfully" verifying the scammer's own signature. the fingerprint comparison is the whole game.
• availability misread - treating an offline genuine site as a scam, then jumping to the first impostor that loads. downtime is normal on tor; check our notes on why mirrors show offline behavior patterns before panicking.

making it a habit

verification only protects you if it happens every time, including the twentieth deposit when you are bored. pin the validator tab, keep the operator's signed announcement saved where you can find it, and treat any address that differs by even one character as hostile until proven otherwise. the tor ecosystem hands you strong primitives - unspoofable addresses, free signatures, local checking tools. using them takes less time than writing down what was stolen.

checking addresses inside tor browser and on phones

the environment you check from changes the mechanics but not the rules. inside tor browser, copy-paste works exactly as elsewhere, but be aware that some clipboard managers on desktop systems keep history - if your operating system syncs clipboard content between devices, that history can carry onion fragments into accounts attached to your legal name. disable clipboard sync or use a manager with history disabled before handling addresses routinely.

on android, tor browser renders .onion links natively, which is convenient and slightly dangerous: tapping a link skips every format check your eyes would have done. get into the habit of long-pressing, copying, and validating first. on ios there is no official tor-native rendering of arbitrary onions outside the endorsed onion browser, so links that promise to open onions directly in safari are a red flag by themselves.

• never let a qr code be the only source of an address - qr codes are trivially regenerated by whoever controls a phishing page
• never trust an address rendered as part of an image; text you cannot select cannot be validated mechanically
• when a site shows a different address than the one in your saved notes, stop and re-derive everything from the official announcement rather than comparing the two suspects against each other

what to do when a known address changes

legitimate services do move: they rotate addresses under ddos pressure, migrate infrastructure, or abandon compromised onions. address changes are also exactly what phishing campaigns simulate, so a rotation claim deserves the same rigor as a first contact.

1. find the change announcement from the operator through a channel that predates the change - their signed pgp messages, their long-lived clearnet site, or their established forum presence.
2. verify the announcement's signature against the fingerprint you recorded the last time you did this exercise.
3. run the new address through the validator and confirm format and checksum before typing it anywhere.
4. check that the old address behaves consistently with the story: an address claimed to be "retired" should usually stop responding, though graceful operators sometimes keep it redirecting for a while.
5. update your records only after all four previous steps pass, and note the date - future-you will want to know how current the information is.

if no verifiable announcement exists, treat the "new address" as unconfirmed no matter how professional the page presenting it looks. downtime plus patience is a far better outcome than uptime plus a cloned login form harvesting your credentials.