Check the publisher before trusting the address

An onion address describes how to route to a service, not who runs it. How to match one against the publisher's own reference, and what to record as you check.

By Dark Web Search editorial · Updated 2026-09-16

What is an onion address?

An onion address is the identifier a Tor onion service is reached by, written as a long string ending in .onion. People also call it an onion domain, but it does not behave like an ordinary domain name: it belongs to the service rather than being chosen as a brand, which is why a familiar-looking prefix establishes nothing about the organization behind it. The address tells you how to route to a service. It does not tell you who operates it, whether it is the same service as last month, or whether anything it publishes is accurate.

How can you tell who controls an onion address?

You cannot tell from the address itself; you establish it from a reference the organization publishes on a channel you already trust. Prefer an onion address announced by the organization on a verified official channel, such as its normal website. If you cannot establish that channel's provenance, say the identity is uncertain rather than inferring it from a familiar logo.

Compare the whole address

Compare every character, not just the beginning or ending. Syntax and checksum validation catch some invalid addresses but do not prove who controls a valid address. Do not replace an old address with a lookalike found in an unverified directory.

Separate the checks

Publisher identity asks who controls the source. Reachability asks whether it responds now. Claim support asks what its text establishes. Record the reference, date and uncertainty for each check; none automatically proves the others.

Use the report path

If a source's recorded provenance or address is wrong, submit its reference and the correction evidence. Avoid posting sensitive research context or an unnecessary directory of links.

A verification record you can reuse

Create a short record with five fields: claimed publisher, complete address, official reference, date checked and conclusion. Use conclusions such as “matches the publisher’s reference,” “reference is outdated” or “publisher association unresolved.” This keeps technical syntax checks separate from the identity question. For a hypothetical newsroom, the strongest starting point is an address published on a newsroom channel you already know belongs to it. A directory entry that copies the newsroom logo is weaker evidence. The record should explain that difference so another researcher can repeat the check.

When two official references disagree

Look for a dated migration or retirement notice. Record both references and the conflict rather than selecting whichever address is more convenient. An older page can remain discoverable after a publisher changes its access instructions. If the publisher provides a normal public support channel, use that channel to resolve the discrepancy without sharing private research details. Do not publish a replacement address until the evidence supports the association. A working destination proves availability of that destination, not that a particular organization controls it.

What to include in a correction

Quote the minimal claim being corrected, identify the page where it appears, and link to the primary evidence. Say whether the problem concerns the address, attribution or date. For example, “the guide cites an old announcement; this newer publisher notice retires it” is actionable. “This site looks suspicious” is a reason to investigate but not a complete correction. Keep sensitive context out of a public correction and use the report route when needed.

Primary references

Tor Project: onion servicesThe Tor Project · read 2026-09-09 · primary source

Related help

Content revision 2026-09-16. AI-assisted editorial content; check the primary references and their dates.