Dark web search engine: the address problem and what engines index

An onion address is a key, not an entry in a list

The Tor Project’s support page says an onion address consists of 56 letters and numbers, followed by .onion, and that the address of an onion service is generated automatically, so the operators do not need to buy a domain name. It adds that, just like any other website, you need to know the address of an onion service to connect to it. A guest post on the project’s blog explains what the 56 characters are: a full ed25519 public key, where the older version 2 address held only the hash of a key and had 16 characters. The support page says a 16-character address no longer works on today’s Tor network. This page is about the mechanism behind search; what an index is, and how the surface, deep and dark web differ, is on our page about the deep web and the dark web.

The project’s documentation on the onion services ecosystem puts a size on the space of possible addresses. Version 3 has, in theory, 256 bits of space, but the actual number is a little smaller, because not every 256-bit number can be a valid public key. The page estimates the space at around 5 bits smaller, a key space in the order of 2 to the power of 251, and compares that with IPv6, which supports 128 bits of address space. It compares bits, so we do not turn it into a ratio of addresses. Brute forcing, the page says, would mean enumerating every value from 0 to 2 to the power of 256, an incomprehensibly large number of addresses with only a tiny fraction being actual services.

The same page says that with version 3, Tor added a mechanism that stops a relay from listing the onion services it may help people reach. Relays can therefore no longer enumerate services efficiently by taking part in the Tor network, and the page calls this property a feature, not a bug.

What the directory shows a count of

Connecting needs more than the address. A research group at the Institute of Network and Security at JKU Linz, in a guest post on the Tor Project’s blog dated 21 September 2021, describes the hidden service directory as the place that holds the information needed to connect to an onion address, much as DNS does for ordinary domain names. It is a distributed hash table formed by all Tor relays that carry the HSDir flag. For version 2, the post says, the data uploaded there was in plain text, so those relays could learn a lot about a small fraction of the running services every day, most importantly the onion address. The post adds that collecting and probing version 2 addresses through such relays is considered malicious behaviour and is sanctioned by the project’s bad-relays team.

Version 3 uses encryption and key derivation. Because the address is itself a public key, the uploaded data can be encrypted, and a client does not ask for the address: Tor calculates a daily-rotated identifier, a “blinded public key”, from the address and the current date and asks for that. The post’s example uses the date 19 August 2021. What stays visible is a count. Every onion address translates to exactly one blinded key per day, so counting the uploaded keys gives a count of the services that are running, a figure the post says the Tor Project already uses in its statistics on version 3 services. It is a count, not a list: the post says version 3 services leak much less sensitive information than version 2 ones.

To see what the data could show, the group ran 50 relays with the HSDir flag, about 1 percent of the directory, and logged every upload and download of blinded keys from 1 March 2021. It registered more than 131 million uploads for about 4.5 million different keys, and more than 225 million download attempts for about 3.4 million different keys. A vast majority of the uploaded keys were never downloaded, which the authors read as services that are barely used. The majority of download requests asked for keys that had never been uploaded, which they read as requests for services no longer operational. Fourteen keys received more than 2 million attempts without any upload, a pattern the authors believe comes from attacks on one service or from a defunct botnet. They give two cautions: six directory relays are responsible for each key by default, so zero downloads seen by their relays does not mean zero use, and the estimate is not as reliable as the statistics at Tor Metrics.

A 2024 paper in Scientific Reports, citing the Tor Project’s statistics, gives about 694 thousand onion domains on 1 January 2023 and adds that onion domains can provide any internet service, and that not all of them host websites. These are counts of keys and domains. The pages we read do not say how many of them are websites a person could search for.

How an engine finds anything at all

The creator of Ahmia, Juha Nurmi, wrote on the Tor Project’s blog on 8 September 2014 that finding web content is hard without a good search engine. The development work the post lists included working out ways to discover hidden service addresses because, in his words, the protocol cannot list them. The post describes what Ahmia did then. A separate script gathered a list called OnionDir of known online hidden service addresses and fetched the title, keywords and description from each page; users could edit those fields. Site administrators could add a file called description.json to offer a description of their own site, and over 80 domains already did. Popularity came from three kinds of data: visit statistics shared by Tor2web nodes, the number of public web links to hidden services, and clicks in the search results. The crawler worked through Tor2web mode. Wikipedia’s text today names GlobaLeaks submissions and Tor2web statistics as partners for discovery.

A crawler study gives the same picture from the other side. Nurmi and co-authors ran parallel crawlers that followed onion links on onion websites and fed the new links to fresh crawlers, and from 2018 to 2023 they collected about 177 thousand unique onion domain addresses. The paper says this method is biased toward websites that are frequently linked, and that it cannot locate onion websites if there are no links to them. A website with several publicly linked addresses has a better chance of being crawled. The Tor Project’s documentation also quotes a forum answer that guesses other engines build their index by scanning public data sets for valid .onion strings. That is one user’s guess in a discussion, not a statement by the project.

The two numbers in this section, about 177 thousand domains collected over five years and about 694 thousand domains counted on one day, are not a coverage ratio. They differ in period, in method and in what they count, so we do not divide one by the other.

Several pages say what stays outside. NordLayer, a company that sells VPN and security products, says the standard crawler design of seed addresses and link structures is ineffective on the dark web because most sites are not interlinked, and that many .onion sites are created to be temporary or invite-only. Breachsense, which sells dark web monitoring, says engines index only public .onion sites, and that private forums requiring registration, invite-only marketplaces and Telegram channels fall outside their reach. The Tor Project’s support page describes an authenticated onion service as one that needs a key from its operator before you can use it. The Tor Project’s support page says nothing about search engines, so that last gap is our inference, and the DeXpose item is about sites that go offline rather than sites outside the index. The figure below sets the five statements side by side.

Ahmia as a worked example

Wikipedia describes Ahmia as a clearnet search engine for Tor’s onion services, created by Juha Nurmi in 2014 and accessible through both its ordinary website and an onion service version, and as one of the primary tools used by Tor users to discover onion websites. It says Ahmia was developed during the 2014 Google Summer of Code with support from the Tor Project. The creator’s own post thanks Google for the stipend and the Tor Project for friendly mentoring, and says the ordinary-web address was registered in 2010 as a side project. We do not give the addresses here. The post lists the parts of Ahmia in 2014 as a Django front end, a PostgreSQL database, Apache Solr for the crawled data and the OnionBot crawler. Wikipedia’s text today names a crawler based on Scrapy, an index built with Elasticsearch and a website built with Django, all open source. These are different years, so the figure below dates each one and does not merge them.

On size, the 2014 post says that at the time there seemed to be 1,228 hidden website domains online and that 7 of them had been filtered. Wikipedia says that as of July 2015 Ahmia had indexed about 5,000 sites. The pages we read do not give a current figure. Neither number is a measure of the network as a whole, and the two use different units, so we do not read them as growth.

On filtering, the 2014 post says Ahmia filters sites related to child abuse, using the MD5 sums of banned domains, and shares that list so that Tor2web nodes can use it. Ahmia’s legal page, which we read, says the indexed sites run inside the Tor network and Ahmia is not responsible for them, and that it cannot guarantee the validity of the information found there. It also says that since October 2023 it filters all sexually related searches, showing a link to a self-help programme instead of results, and applies an automated text mining algorithm to remove possible links to child abuse from results.

Two measurements show how much weight one engine can carry. A 2018 USENIX survey, quoted in the Scientific Reports paper, found that the three most popular ways participants discovered onion sites were social networking sites such as Twitter and Reddit (48 percent), search engines such as Ahmia (46 percent) and links met while browsing the web (46 percent). We did not read the USENIX paper, so the figures are second-hand, and they describe survey participants, not all users. An arXiv preprint dated 10 March 2026, which we cite as a preprint, describes an experiment in March and April 2025: the authors placed neutral-looking links to decoy onion sites in Ahmia, on Stronghold Paste and on pastebin.com. Of about 219 thousand visits between 26 March and 10 April 2025, 87.6 percent came from Ahmia, 6.4 percent from pastebin.com and 5.9 percent from Stronghold Paste. The exposure was not equal: the preprint says the links stayed in Ahmia’s results until 10 April, while the two paste sites showed them for one day only, 24 March, and the authors modified Ahmia’s search to add the decoy links at random (Juha Nurmi, Ahmia’s creator, is among the preprint’s authors). The preprint itself compares Ahmia with the paste sites on the first day only. The authors write that, almost without exception, human users came from Ahmia, judged by solved CAPTCHAs and registration attempts, and that when the links were removed from Ahmia’s results visits dropped to nearly zero. Visits to the paste sites after the first day came mainly from automated systems that collect links. The comparison is not like for like, and the authors note that Ahmia is a Finnish engine, so its users may not mirror those of other engines. The 87.6 percent therefore says where visitors came from among these three channels, not how much of all discovery goes through Ahmia.

Stale results and copies

DeXpose says search on the dark web is slower, more limited and less refined than on the surface web, and that some sites disappear with no warning and return weeks afterwards at a new address. NordLayer says Torch is one of the oldest dark web search engines, that its index is broad but not always reliable, and that it often returns outdated or broken links. Breachsense says results are often outdated because sites go offline frequently. Tor Browser’s own error table lists “Onionsite Not Found” and gives the most likely cause as the onion site being offline, and the support page says site operators may have let a service go offline without warning.

Copies are the other problem. Ahmia’s legal page carries a warning that a man-in-the-middle fake clone was detected, and tells the reader to find the real address from the ordinary-web site; we do not repeat either address here. Wikipedia says that in July 2015 Ahmia published a list of hundreds of fraudulent clones of web pages, including clones of sites such as DuckDuckGo, and quotes Nurmi as saying the clones aim at scamming people, for example gathering bitcoin by spoofing bitcoin addresses.

The support page explains why an address matters: the page ties this to the cryptography involved, and says the address is what lets Tor confirm that it has reached the intended service. It also says that even a small mistake in an address will stop Tor Browser from reaching the site. Putting the two together is our reasoning, not a sentence from either page: an address that differs by a character is a different address, so a copied or mistyped one leads somewhere else rather than to a slightly wrong version of the same place. For a site you already know on the ordinary web, the support page describes Onion-Location, a non-standard HTTP header that a website can use to advertise its onion counterpart; Tor Browser then shows a purple “.onion available” prompt in the address bar. Our page on whether Tor Browser is safe covers the browser itself.

What the two measurements say together

Put the pieces together. Relays are kept from enumerating services, a crawler finds what is linked, and survey participants say they find onion sites through social networks, engines and links. In the 2025 experiment most of the human engagement, meaning solved CAPTCHAs and registration attempts, came through one engine, although the links stayed in that engine’s results for weeks and on the paste sites for one day. Our reading is that the two measurements point in different directions: the survey has three channels at about half of participants each, while the decoy-site experiment, which used three channels placed by the authors for different lengths of time, saw most human engagement come through one engine. Neither shows how much of all discovery goes through any single channel. That is our reading of survey answers and decoy-site visits, not a figure from either source.

The Scientific Reports paper tested the 26 most-visited Tor search engines, ranked by clicks on 17 March 2023, and found that 21 of them returned results for child sexual abuse material, while five attempt to block it. The paper also says that a user can use engines that block it to locate other engines. Its Author contributions section says the first author operates the Ahmia search engine, which is worth knowing when the paper describes Ahmia’s filter. The sources also differ on dates: Ahmia’s legal page and Wikipedia put the wider filter in October 2023, while the paper says the first author decided on it in November 2023, after the research.

On which engine is best, the vendors differ and give judgments, not measurements. NordLayer says no “best” engine exists, calls Ahmia’s index relatively shallow and says it filters. Breachsense lists Ahmia as suited to safe research and beginners. KELA, a threat intelligence company, says Ahmia has had Tor Project support since 2014, which agrees with Wikipedia; the creator’s own post speaks only of mentoring in the Summer of Code. The pages we read do not compare how much of the network each engine covers. If you are here because a company says your details turned up on the dark web, our page on what a data breach means is the one to open; for the network itself, see bridges and censorship.

What we did not use

We ran no search on any dark web engine and gave no address on this page. We did not read the 2018 USENIX paper, so its figures reach us through the Scientific Reports paper. Ahmia’s home page and blacklist page reached us as short pages of search form and menus, so we did not cite them; its legal page is the one we read. The vendor pages from NordLayer, KELA, Breachsense and DeXpose sell VPN, monitoring or security products, and we used them only to say what they claim about engines, not as proof.