How to spot a fake onion mirror in 2026 before it costs you

Tricks torverify sees again and again

• Look-alike addresses. A clone registers a v3 onion whose first few characters match the real one, betting you check the start and skip the rest.
• Padded mirror lists. A page lists ten addresses, nine fake, and dares you to guess. The real one may not even be there.
• Borrowed trust. A copied logo, a “verified” graphic, or a stolen review section, none of which cost the attacker anything.
• Urgency. “Old link dead, use this new one now.” Pressure exists to stop you checking.
• Search and forum seeding. Fresh clones get posted where you are likely to search, so the first result is not the safe one.

Why torverify treats all five the same way

Each trick above targets a different habit — skimming, guessing, trusting a badge, rushing, trusting rank — but torverify's answer to all five is identical: nothing here substitutes for a signature check against a source that exists independent of the page you're looking at. That single answer is deliberately boring, because boring and repeatable is what actually holds up against five different attack shapes.

torverify's routine that beats a clone

1. Start from a signed source. Read the address from a record you trust, such as torverify's signed source, not from a link you were handed.
2. Read all 56 characters. Compare the whole string, not the first few. One wrong character is a different service.
3. Check the signature. Confirm the PGP signature over the source on torverify's PGP tool.
4. Copy, do not click. Select the address as text and paste it into Tor Browser yourself.

Why torverify orders torverify's routine this way

Starting from a signed source rather than a random link removes most phishing attempts before step two even matters — a link handed to you by a stranger has already failed the first requirement. The remaining steps exist for the harder case: a link that looks legitimate enough to warrant an actual check.

Common mistakes torverify sees that make phishing work

torverify sees the same handful of mistakes behind almost every successful onion phishing case — naming them plainly is most of the defense.

Mistake 1: verifying under time pressure

Every trick on this page is more effective the faster you act. Slowing down by even thirty seconds to run torverify's routine above defeats urgency-based phishing almost by itself, because urgency is the entire mechanism, not a side effect of it.

Mistake 2: trusting a source because it's familiar

A forum you've used for years, a search engine you trust, a link a friend sent — familiarity is not the same as verification, which is the whole reason torverify exists as a separate check. Clones get seeded into exactly these familiar channels precisely because familiarity lowers guard.

Mistake 3: checking the signature but not the address, or vice versa

Both checks matter and neither substitutes for the other. An address that matches with no valid signature, or a signature that's valid but over the wrong address, both fail torverify's routine — see the signature guide and the mirror guide for each half in detail.

Worked example: torverify's routine when a mirror link arrives unsolicited

A message drops into a channel you follow: "official mirror, old one is down, use this now." Here is torverify's routine applied to that exact situation.

Step 1 — do not click the link in the message

Treat the linked address as unverified by default, regardless of who posted it or how official the message looks.

Step 2 — find the project's entry on torverify independently

Navigate to torverify's verify index yourself, not through any link in the suspicious message, and locate the project's current entry.

Step 3 — compare character by character, then check the signature

Compare the message's address against torverify's record in full, then confirm the signature on the PGP tool before treating either address as safe to open.

Reporting a fake

If you find a mirror impersonating one of the projects torverify lists, note the exact address and where you found it. Cross-checking it against the signed source is usually enough to confirm it is not genuine. The more people who verify before they trust, the less a clone earns for existing.

Why Tor has no certificate authority to catch this automatically

On the ordinary web, a browser padlock means a certificate authority vouched that a domain belongs to whoever presented the certificate — an imperfect system, but one that catches a large share of naive phishing automatically. The .onion namespace has no equivalent authority by design: an onion address is derived directly from its own public key, which means anyone can generate a new one for free, instantly, with no registration and no external gatekeeper to say no. That property is a genuine privacy feature, but it also means the entire burden of telling a real address from a clone falls on the visitor, not on any infrastructure watching for you.

Why this makes onion phishing structurally different from clearnet phishing

A clearnet phishing domain typically has to either fool a certificate authority, use a lookalike domain a registrar will happily sell, or rely on a user ignoring browser warnings. None of those obstacles exist on Tor: a clone operator can generate onion addresses by the thousand until one happens to share a convincing prefix with the real service, and Tor Browser will show exactly the same padlock-equivalent trust indicators for the clone as for the genuine site, because cryptographically the clone's address is just as "real" as any other — it simply is not the address the operator actually controls.

What actually fills the gap left by the missing authority

Independent, out-of-band verification like torverify's routine on this page is what fills that gap: a signed source of record that exists outside the address itself, checked through a channel — PGP, in torverify's case — that a clone cannot forge without also compromising the signing keys. That is a heavier lift for an ordinary visitor than glancing at a padlock, which is exactly why phishing remains so effective on Tor even against people who would never fall for a clearnet lookalike domain.

The anatomy of a convincing onion clone, piece by piece

torverify's operators have looked at enough phishing mirrors to notice they reuse the same handful of building blocks, assembled slightly differently each time. Knowing the pieces makes any new combination easier to recognize on sight.

The address: close enough to survive a glance

A clone's address is chosen to pass a fast glance, not a real check — a matching prefix, a familiar-looking suffix, or occasionally a homoglyph substitution that looks identical in most fonts. torverify's routine defeats this piece specifically because it never trusts a glance; a full 56-character comparison against a signed source catches every variant of this trick equally.

The page: a pixel-for-pixel copy

Cloning a page's HTML, CSS, and images is trivial and costs an attacker nothing — view-source and save is most of the work. This is exactly why torverify's methodology never treats visual polish as evidence of anything; a perfect copy of a legitimate page proves the attacker can copy files, not that they control the real service.

The badge: borrowed authority

A "verified," "official," or "audited" graphic pasted onto a clone borrows the credibility of whatever real verification system it imitates, without actually passing that system's check. torverify's own badge-equivalent, a LEGIT verdict, is meaningless if copied as an image — the actual proof lives in the signature check, not in any graphic that could appear next to the address.

The urgency: a deadline that isn't real

"This link expires soon" or "old address suspended" manufactures a reason to skip verification. Onion addresses do not expire on a schedule; a service you already trust does not suddenly require a new, unverified address without a signed announcement on torverify or a channel equally hard to fake.

Where phishing kits for onion mirrors actually come from

Most onion phishing is not bespoke. torverify's operators have observed the same small set of reused templates behind a large share of the clones people report, which explains why a phishing page for one market can look eerily similar to one targeting an entirely different market.

Template reuse across unrelated targets

A phishing kit built once, with placeholder logos and colors, gets reskinned for whichever market is currently popular enough to be worth impersonating. This is one reason torverify's verify pages are organized per-project rather than as a single generic warning — the underlying attack infrastructure repeats even when the target brand changes.

Automated address generation at scale

Grinding thousands of candidate v3 onion addresses looking for a convincing prefix match is computationally cheap and fully automatable; an attacker does not hand-pick a single lookalike address, they generate a batch and keep whichever ones look closest. That scale is precisely why torverify insists on a full-string, not a prefix, comparison — a prefix match tells you nothing about how many addresses were discarded to get it.

Distribution through search and social seeding

Once a clone kit is built, distributing it costs little more than posting links in forums, comment sections, and search-indexed pages, betting on volume rather than precision. torverify cannot stop that distribution — no verification reference can — but a reader who runs the routine on this page before trusting any single one of those links removes the entire economic incentive behind the volume approach.