How Onion Services Work

Onion services are one of the most distinctive features of the Tor network. They allow websites and other internet services to operate without revealing the physical location or public IP address of the server, while also allowing users to connect without exposing their own IP address to the service. Unlike ordinary websites, which are reached through the public Domain Name System and conventional internet routing, onion services are reached through the Tor network and use addresses ending in .onion.

The purpose of an onion service is not simply to “hide a website.” Its real function is to create a privacy-preserving communication model where both sides — the visitor and the service — meet through Tor circuits instead of connecting directly. This design makes onion services useful for journalism, whistleblowing platforms, human rights organizations, privacy-preserving communication, research archives, censorship-resistant publishing, and communities that need stronger protection against surveillance or location-based attacks.

The basic idea

On the regular web, a browser connects to a server by resolving a domain name, finding the server’s IP address, and establishing a connection across the internet. Even when HTTPS is used, the server’s network location is still part of the connection process. The user may not know the server’s real identity, but the internet infrastructure must know where packets are going.

Onion services work differently. A visitor does not connect directly to the server. The server also does not directly connect back to the visitor. Instead, both sides build separate encrypted paths through Tor and meet at a temporary relay selected for that connection. This relay is called a rendezvous point.

Because the visitor and the onion service never connect directly, the visitor does not learn the server’s IP address, and the server does not learn the visitor’s IP address. The Tor network carries the traffic between them through layered encryption and carefully separated circuits.

Why they are called “onion” services

The name comes from Tor’s layered encryption model, often compared to the layers of an onion. When Tor sends traffic through a circuit, each relay only knows the previous hop and the next hop. No single relay in the path has the full picture of who is communicating with whom.

For onion services, this principle is extended further. Both the client and the service build Tor circuits, and the connection is completed without either side revealing its network location to the other. The result is a system where routing, authentication, and service discovery are handled inside Tor itself.

What a .onion address represents

A modern v3 .onion address is not just a normal domain name. It is derived from cryptographic identity material belonging to the onion service. In simplified terms, the address is tied to the service’s public identity key, plus additional data such as a checksum and version information.

This is why v3 onion addresses are long, random-looking strings. Their length is not an accident or a branding choice; it is part of the security model. A .onion address is self-authenticating: when a client connects to it, the address itself helps verify that the client is reaching the service associated with that cryptographic identity.

This is very different from a traditional domain such as example.com, where trust depends on DNS, certificate authorities, registrars, and hosting infrastructure. With onion services, the address is directly linked to the service’s cryptographic identity.

The main components of an onion service connection

To understand how onion services work, it helps to separate the system into a few important roles.

The onion service

The onion service is the website, application, or server that wants to be reachable through Tor. It may be a web server, a chat service, an API, a file repository, or another type of internet service. The important point is that it is configured to accept traffic through Tor rather than exposing its real network location to the public internet.

Introduction points

An onion service first chooses several Tor relays to act as introduction points. These relays do not know the real location of the service. They only know that they are responsible for forwarding introduction messages through an already established Tor circuit.

The service keeps circuits open to these introduction points. This allows clients to contact the service indirectly without knowing where the service is hosted.

Hidden service directories

The onion service publishes a descriptor to special Tor relays known as hidden service directories or HSDirs. The descriptor contains the information a client needs in order to contact the service’s introduction points.

The descriptor does not reveal the server’s IP address. In v3 onion services, important descriptor information is protected cryptographically, reducing the ability of unrelated parties to collect or inspect onion service information at scale.

The client

The client is the Tor user trying to visit the onion service. Usually this is done through Tor Browser, although other Tor-aware software can also connect to onion services.

When the client enters a .onion address, Tor does not ask the public DNS system where that address is. Instead, it uses the onion address to locate the service descriptor inside the Tor network.

The rendezvous point

The rendezvous point is a temporary Tor relay chosen by the client for a specific connection. It is where the client’s circuit and the service’s circuit meet.

The rendezvous point does not need to know the identity of the client or the physical location of the onion service. It simply relays encrypted traffic between the two Tor circuits.

Step-by-step: how a connection is created

1. The onion service prepares itself

Before anyone connects, the onion service creates its cryptographic identity and receives its .onion address. The service then builds Tor circuits to several introduction points. These introduction points become the public contact layer for the service inside the Tor network.

The service also creates a descriptor that lists the introduction points and contains the information needed for clients to begin the connection process.

2. The descriptor is published

The descriptor is uploaded to selected HSDirs in the Tor network. These directories function as a distributed lookup system for onion services.

This does not work like ordinary DNS. There is no central registry where every onion service is listed by name. Instead, the Tor protocol determines where descriptors should be stored and how clients can retrieve the right descriptor when they already know the onion address.

3. The visitor enters the .onion address

When a user enters a .onion address in Tor Browser, the browser passes the request to Tor. Tor uses the address to determine where the relevant descriptor should be found.

The client retrieves the descriptor from the appropriate HSDirs. This gives the client the information needed to contact one of the service’s introduction points.

4. The client chooses a rendezvous point

The client then selects a Tor relay to serve as a rendezvous point for this session. The client builds a Tor circuit to that rendezvous point and prepares a message explaining where the service should meet it.

This message does not reveal the client’s IP address. It only tells the onion service how to reach the chosen rendezvous point through Tor.

5. The client contacts an introduction point

The client sends an introduction message to one of the onion service’s introduction points. The introduction point forwards this message to the onion service through the service’s existing Tor circuit.

At this stage, the introduction point acts only as a messenger. It does not connect directly to the service’s hosting location, and it does not become the final communication channel.

6. The onion service connects to the rendezvous point

If the onion service accepts the request, it builds its own Tor circuit to the rendezvous point selected by the client. The service then completes the rendezvous process.

Now the client and the onion service are connected through Tor, but neither side has connected directly to the other.

7. Encrypted communication begins

Once the rendezvous is complete, application traffic can flow between the client and the onion service. For example, a website can load in Tor Browser just as a regular website would load in another browser.

The difference is that the traffic remains inside Tor’s onion service architecture. The user does not need to know the server’s IP address, and the server does not need to know the user’s IP address.

Why onion services do not need exit nodes

A common misconception is that all Tor traffic uses exit nodes. This is true when Tor users visit ordinary websites on the public internet, because the traffic must eventually leave the Tor network and reach a normal server.

Onion services are different. The connection stays inside the Tor network from end to end. Since the destination is also inside Tor, there is no need for an exit node.

This has two important consequences. First, the risks associated with malicious exit nodes are reduced because no exit node is involved. Second, the entire path between the client and the onion service remains part of the Tor network.

Privacy properties

Onion services provide several privacy advantages when used correctly.

First, they protect the location of the server. The service can operate without exposing its public IP address to visitors, crawlers, hosting attackers, or ordinary network observers.

Second, they protect the location of the visitor. The onion service does not receive the visitor’s real IP address because the visitor connects through Tor.

Third, they provide a form of cryptographic identity. A v3 onion address is tied to the service’s identity key, which makes the address itself part of the authentication model.

Fourth, they avoid the need for public DNS resolution. Since .onion addresses are resolved inside Tor, the user does not rely on normal DNS infrastructure to locate the service.

Limitations and realistic risks

Onion services are powerful, but they are not magic. They do not automatically make every website secure, trustworthy, or anonymous in every possible way.

A poorly configured server can still leak information. Web applications can still have vulnerabilities. Administrators can still make operational security mistakes. Users can still be phished by fake onion addresses. Traffic analysis attacks may still be a concern against powerful adversaries, especially when an attacker can observe large parts of the network or repeatedly interact with a target service.

The content of a website also matters. If a user logs into an account that reveals personal information, downloads unsafe files, enables risky browser behavior, or shares identifying details, Tor cannot undo those mistakes.

In other words, onion services protect the network path, but they do not replace good security practices.

Onion services and HTTPS

Because onion services already provide encryption and authentication at the Tor protocol level, some onion sites do not use HTTPS. However, HTTPS can still be useful in many cases, especially for familiar browser security indicators, defense in depth, reverse proxy setups, and consistency with clearnet versions of the same service.

For public-facing organizations, offering both a normal HTTPS website and an official onion mirror can improve accessibility and censorship resistance. The important point is that users must verify that the onion address is authentic, preferably from a trusted official source.

Common misconceptions

“Onion services are only for illegal activity”

This is incorrect. Onion services are a privacy technology. Like many technologies, they can be misused, but they also support legitimate and important use cases. Journalists, researchers, activists, civil society groups, software projects, and privacy-conscious organizations use onion services to protect access, resist censorship, and reduce exposure to surveillance.

“A .onion address works like a normal domain”

A .onion address is not resolved through ordinary DNS. It is part of Tor’s internal naming and routing system. This is why .onion addresses require Tor-aware software such as Tor Browser.

“The introduction point knows where the server is”

The introduction point does not need to know the real server location. The onion service reaches the introduction point through a Tor circuit, so the introduction point only sees the Tor-side connection.

“The rendezvous point controls the connection”

The rendezvous point relays encrypted traffic between two Tor circuits. It helps complete the connection, but it does not need to know the identity or location of both parties.

“Onion services guarantee trust”

An onion service can prove continuity of cryptographic identity through its address, but that does not mean the operator is honest, safe, or legitimate. Users still need judgment, verification, and caution.

Why onion services matter

The importance of onion services goes beyond the dark web stereotype. They represent a different model of internet publishing: one where a service can be reachable without exposing its infrastructure, and where users can connect without revealing their network location to the destination.

This is especially valuable in hostile environments. A news organization may use an onion service to receive sensitive tips. A human rights group may use one to keep resources available in censored regions. A software project may provide an onion mirror so users can download tools when ordinary access is blocked. A private community may use onion services to reduce unnecessary exposure to commercial tracking and network surveillance.

The core idea is simple but powerful: communication can happen without either side needing to reveal more network information than necessary.

Best practices for users

Users should access onion services through Tor Browser and avoid opening .onion links in ordinary browsers. They should verify onion addresses from official or trusted sources, bookmark important addresses, and be cautious with lookalike links.

Users should also avoid sharing personal information unless they fully trust the service and understand the risks. Files downloaded from unknown sources should be treated carefully, and browser security settings should not be weakened casually.

For directories and research references, users should prefer organized, curated sources instead of random link lists. A resource such as In The Hidden Wiki can be used as a starting point for learning about onion links, tor links, and hidden web navigation, but every destination should still be evaluated critically.

Best practices for operators

Operators should isolate onion service infrastructure from personal or unrelated systems. They should avoid exposing administrative panels, server headers, analytics scripts, debug pages, or metadata that could reveal hosting details.

They should keep Tor and the web server updated, monitor logs carefully without collecting unnecessary user data, and design the service with privacy in mind from the beginning. If the onion service is an official mirror of a public website, the onion address should be published on a trusted official channel so users can verify it.

Operators should also remember that anonymity is an operational discipline, not just a configuration option. A single mistake in hosting, content, payments, accounts, or metadata can weaken the privacy benefits of the entire setup.

Conclusion

Onion services work by replacing direct client-server connections with a privacy-preserving rendezvous system inside the Tor network. The service publishes encrypted reachability information, the client retrieves that information, both sides build Tor circuits, and communication begins at a rendezvous point without either side exposing its real IP address to the other.

This architecture is one of the most advanced privacy designs available on the internet. It combines cryptographic identity, distributed service discovery, layered routing, and location protection into a single system. Used responsibly, onion services can support privacy, free expression, censorship resistance, secure publishing, and safer access to sensitive information.

Their strength comes from a careful balance: they make services reachable while revealing as little as possible about where those services are hosted or who is visiting them. That is what makes onion services a unique and important part of the modern privacy ecosystem.

References

Tor Project. How do Onion Services work?
Tor Project. Onion Services protocol documentation.
Tor Project. V3 Onion Services usage and privacy improvements.
Tor Project Support. Onion services in Tor Browser.