Onion Services
Onion services are network services that can be reached through the Tor network without revealing the public IP address or physical network location of the server. They are most commonly accessed through addresses ending in .onion, which are resolved inside Tor rather than through the public Domain Name System.
Onion services are one of the most important privacy technologies developed within the Tor ecosystem. They allow a website, application, chat system, file service, API, or other internet service to be reachable while protecting the location of both the visitor and the service operator. Unlike ordinary websites, where a user connects to a server’s public IP address, onion services use Tor circuits, introduction points, hidden service directories, and rendezvous points to create a connection without either side directly exposing its network location to the other.
Although onion services are often associated with the dark web, their purpose is broader than secrecy. They are used for privacy-preserving publishing, censorship resistance, secure journalism, whistleblowing platforms, human rights work, research archives, software distribution, secure communication, and services that require stronger protection against surveillance or location-based attacks.
Definition
An onion service is a service reachable through the Tor network using a special address ending in .onion. These services are sometimes called hidden services, although the modern Tor documentation generally prefers the term onion services.
The word “hidden” can be misleading. Onion services are not necessarily secret in the sense of being unknown. Some are public and widely advertised. What is hidden is the service’s network location. A public onion service can be known to millions of users while still keeping its server IP address private.
A simple way to define onion services is:
An onion service is a Tor-accessible service whose address is tied to a cryptographic identity and whose server location is protected by Tor’s rendezvous architecture.
This makes onion services different from ordinary websites, VPN-protected websites, private databases, and unindexed deep web pages.
Onion services and .onion addresses
A .onion address is not a normal domain name. It does not rely on public DNS servers, domain registrars, or traditional name resolution. Instead, .onion addresses are special-use names recognized for Tor onion services.<ref name="rfc7686">IETF, RFC 7686: The ".onion" Special-Use Domain Name. https://datatracker.ietf.org/doc/html/rfc7686</ref>
Modern v3 onion addresses are long because they are derived from cryptographic identity material. This means the address is not merely a pointer to a server. It is connected to the onion service’s public identity key.
This gives onion addresses an important property: they are self-authenticating. If a user has the correct onion address, the Tor protocol can verify that the service being reached corresponds to that cryptographic identity.
This is very different from a traditional domain such as example.com. A normal domain depends on DNS, registrars, certificate authorities, hosting infrastructure, and public routing. A .onion address depends on Tor’s internal service discovery and cryptographic identity system.
Why onion services matter
Onion services matter because they change the relationship between users, servers, and the network.
On the ordinary web, a visitor usually reveals their IP address to the destination server, unless they use a proxy, VPN, or anonymity network. The server also exposes its public IP address or hosting infrastructure to the internet. Even when HTTPS protects the content of the connection, network metadata can still reveal who is connecting and where the service is hosted.
Onion services reduce this exposure. The visitor connects through Tor, and the service is also reached through Tor. The visitor does not connect directly to the server, and the server does not directly connect to the visitor.
This architecture is valuable for people and organizations that need privacy, resilience, or censorship resistance. It can protect journalists receiving sensitive information, activists publishing under pressure, users in censored regions, researchers studying sensitive topics, and organizations that want to offer privacy-preserving access to their services.
How onion services work
Onion services use a rendezvous model. Instead of the client connecting directly to the server, both sides build separate Tor circuits and meet at a temporary relay called a rendezvous point.<ref name="tor-overview">Tor Project Community, How do Onion Services work? https://community.torproject.org/onion-services/overview/</ref>
This process involves several components:
- The onion service.
- The client.
- Introduction points.
- Hidden service directories.
- Service descriptors.
- Rendezvous points.
- Tor circuits.
Each component plays a specific role in allowing the connection to happen without revealing the real network location of either side.
The onion service
The onion service is the server or application that wants to be reachable through Tor. It may host a website, search engine, chat system, file repository, API, forum, documentation archive, or other internet service.
The onion service generates cryptographic identity material. From this identity, Tor creates the .onion address. The service then advertises how it can be contacted inside the Tor network, but it does not publish its real IP address.
The onion service does not wait for users on the open internet. Instead, it establishes Tor circuits to selected relays that act as introduction points.
Introduction points
Introduction points are Tor relays chosen by the onion service. The service builds Tor circuits to these relays and asks them to act as contact points.
An introduction point does not know the real location of the onion service. It only knows that it is receiving introduction messages through a Tor circuit. Its job is not to host the service, identify the server, or inspect the final communication. Its job is to pass introduction requests from clients to the onion service.
This design prevents users from needing to know where the onion service is hosted. Users only need the .onion address.
Hidden service directories
Hidden service directories, often called HSDirs, store onion service descriptors. A descriptor is a small piece of information that allows clients to find the service’s introduction points.
The descriptor does not reveal the server’s IP address. It gives the client enough information to begin the introduction process, but not enough to locate the server directly.
This is one of the reasons onion services do not work like ordinary DNS. A .onion address is not looked up in the global DNS system. Instead, Tor uses the onion address to locate the appropriate descriptor inside the Tor network.
Service descriptors
A service descriptor tells clients how to contact an onion service through Tor. It includes information about the service’s introduction points and cryptographic material needed for the connection process.
In modern v3 onion services, descriptors are protected and distributed in a way that improves privacy and security compared with older onion service designs.<ref name="rendv3">Tor Project, Tor Rendezvous Specification - Version 3. https://torproject.gitlab.io/torspec/rend-spec-v3.html</ref>
Descriptors are essential because they allow a client to begin contact with the onion service without requiring a direct address for the server.
Rendezvous points
A rendezvous point is a temporary Tor relay selected by the client. It acts as the meeting place between the client’s Tor circuit and the onion service’s Tor circuit.
The rendezvous point does not need to know who the client is or where the onion service is hosted. It simply relays encrypted traffic between the two Tor circuits.
This is the central idea behind onion services: the client and the service meet inside the Tor network without directly revealing themselves to each other.
Step-by-step connection process
The onion service connection process can be understood in several stages.
The service creates its identity
The onion service generates cryptographic keys. These keys are used to create the .onion address and to prove that the service corresponds to that address.
This identity is important because it allows the .onion address to function as more than a normal domain name. The address is tied to the service’s cryptographic identity.
The service selects introduction points
The onion service chooses several Tor relays as introduction points. It builds Tor circuits to them and keeps those circuits available.
These introduction points become the service’s contact layer inside the Tor network.
The service publishes its descriptor
The service publishes a descriptor to selected HSDirs. The descriptor tells clients which introduction points can be used to reach the service.
This descriptor does not disclose the service’s IP address.
The client enters the .onion address
When a user enters a .onion address in Tor Browser, the browser does not use public DNS. Instead, Tor uses the onion address to locate the appropriate descriptor inside the Tor network.
The client retrieves the descriptor and learns how to contact the service’s introduction points.
The client selects a rendezvous point
The client chooses a Tor relay to act as the rendezvous point for this session. The client builds a Tor circuit to that relay and prepares a message for the onion service.
This message tells the service where to meet the client, but it does not reveal the client’s real IP address.
The client contacts an introduction point
The client sends an introduction message to one of the service’s introduction points. The introduction point forwards this message to the onion service through the existing Tor circuit.
The introduction point is only a messenger. It is not the final communication path.
The onion service connects to the rendezvous point
If the service accepts the request, it builds its own Tor circuit to the rendezvous point selected by the client.
Now both sides have circuits to the same relay.
Communication begins
Once the rendezvous is complete, encrypted communication can begin between the client and the onion service.
The client does not learn the server’s real IP address, and the server does not learn the client’s real IP address. The connection remains inside the Tor network.
Why onion services do not use exit nodes
When Tor users visit ordinary websites, traffic must eventually leave the Tor network through an exit relay. This is because the destination is on the public internet.
Onion services are different. The destination is also inside Tor. The client connects through Tor, and the service is reached through Tor. Because of this, the traffic does not need to exit to the public internet.
This is an important advantage. Onion service connections avoid many risks associated with exit relays because no exit relay is involved. The connection remains within Tor from end to end.
Onion services and HTTPS
Onion services provide encryption and authentication at the Tor protocol level. This means a .onion connection already has security properties that ordinary HTTP websites do not have.
However, HTTPS can still be useful for onion services. It may provide defense in depth, familiar browser security indicators, compatibility with existing infrastructure, and consistency between clearnet and onion versions of a service.
For official organizations, HTTPS can also help users recognize that the onion service belongs to the same entity as the public website. However, the most important step is still verifying the onion address from an official source.
A .onion site without HTTPS is not automatically unsafe, but HTTPS can still be beneficial depending on the use case.
Onion services and anonymity
Onion services can protect both sides of a connection, but they do not guarantee perfect anonymity.
They help protect the client’s IP address from the service and the service’s IP address from the client. They also reduce exposure to traditional DNS and public routing infrastructure.
However, anonymity can still be weakened by:
- Browser vulnerabilities.
- User mistakes.
- Unsafe downloads.
- Logging into personal accounts.
- Reusing usernames.
- Revealing personal information.
- Server misconfiguration.
- Traffic analysis.
- Operational security failures.
- Malware.
- Compromised hosting environments.
- Correlation attacks by powerful adversaries.
Onion services protect the network path, but they do not eliminate every possible risk.
Onion services and the dark web
Many dark web websites are onion services, but the two terms are not identical.
The dark web is a broad term for services intentionally hidden behind anonymity networks. Onion services are the Tor-specific technology used to create many of those services.
Not all onion services are illegal, suspicious, or secret. Many are legitimate privacy-preserving services. Examples include secure submission systems, official mirrors, privacy tools, research resources, communication platforms, and censorship-resistant publishing.
The technology is neutral. Its ethical and legal meaning depends on how it is used.
Legitimate uses of onion services
Onion services support many legitimate use cases.
Journalism
Journalists may use onion services to receive sensitive documents, protect sources, and provide access to news in censored regions.
SecureDrop, for example, is a well-known system used by media organizations for secure whistleblower submissions, and it commonly relies on onion services.
Human rights
Human rights organizations may use onion services to publish information, receive reports, or communicate with people in dangerous environments.
For users facing surveillance, anonymity may be essential for safety.
Censorship resistance
Onion services can help users access information when ordinary websites are blocked. Because the service is reachable inside Tor, it may remain available even when its clearnet domain is censored.
Privacy-preserving mirrors
Some organizations provide onion mirrors of their public websites. These mirrors allow users to access the same or similar information with stronger network privacy.
Research and education
Researchers may study onion services to understand anonymity networks, cybercrime, censorship, privacy systems, human behavior, and internet measurement.
Secure communication
Onion services can support private messaging systems, internal tools, hidden APIs, or services that should not expose their network location.
Onion services and usability
Onion services have strong privacy properties, but they also face usability challenges.
Modern .onion addresses are long and difficult to remember. This makes them resistant to certain forms of impersonation, but also makes them hard for humans to read, type, compare, and verify.
Academic research has found that users often have incomplete mental models of onion services, may struggle to authenticate onion addresses, and may have difficulty discovering and tracking legitimate onion sites.<ref name="winter2018">Philipp Winter, Anne Edmundson, Laura M. Roberts, Agnieszka Dutkowska-Zuk, Marshini Chetty, and Nick Feamster, How Do Tor Users Interact With Onion Services?, USENIX Security Symposium, 2018. https://www.usenix.org/system/files/conference/usenixsecurity18/sec18-winter.pdf</ref>
This usability problem matters because privacy tools must be understandable. If users cannot verify addresses or understand warnings, they may become vulnerable to phishing and impersonation.
Phishing and fake onion addresses
Phishing is one of the most serious risks in the onion service ecosystem.
Because onion addresses are long, attackers may create fake pages that imitate legitimate services. A user who obtains an address from an unreliable source may end up on a malicious copy.
Users should verify important onion addresses from official sources whenever possible. If an organization has a public website, it should publish its official onion address there. Users should bookmark verified addresses instead of repeatedly copying them from random directories or messages.
Directories can be useful, but they should never be treated as automatic proof of authenticity.
Onion service directories
Onion service directories organize .onion links into categories. They may list search engines, privacy tools, forums, news resources, archives, communication services, and educational pages.
A good directory should prioritize clarity, verification, safety notes, and regular maintenance. A poor directory may contain dead links, scams, phishing copies, malware pages, or outdated addresses.
For research-oriented navigation, users may consult organized references such as In The Hidden Wiki to learn about onion links, tor links, hidden web categories, and privacy resources. However, every important destination should still be verified independently, and users should not assume that any directory can guarantee safety.
Security properties of onion services
Onion services provide several important security properties.
Server location privacy
The service can be reachable without exposing its server IP address to visitors.
This can protect the operator from direct network attacks, censorship, hosting pressure, and location discovery.
Client location privacy
The service does not receive the client’s real IP address. The client connects through Tor circuits.
This helps protect users from tracking by the destination service.
Self-authenticating addresses
Modern onion addresses are tied to cryptographic identity material. This allows the address itself to help authenticate the service.
No ordinary DNS dependency
Onion services do not depend on public DNS resolution. This reduces exposure to DNS blocking, DNS surveillance, DNS spoofing, and registrar-level pressure.
End-to-end Tor routing
The connection remains inside Tor and does not require an exit relay.
This reduces exposure to exit-node risks present when visiting ordinary websites through Tor.
Limitations of onion services
Onion services are powerful, but they have limitations.
Performance
Onion services are often slower than ordinary websites. Traffic moves through multiple Tor relays and layered encryption. This can increase latency and reduce bandwidth.
Onion services are not ideal for all high-performance or latency-sensitive applications.
Availability
Many onion services are maintained by individuals, small communities, or experimental projects. They may go offline frequently, change addresses, or disappear without notice.
Discovery
Finding legitimate onion services can be difficult. Search engines and directories may be incomplete, outdated, or unreliable.
Trust
A valid .onion address proves continuity of cryptographic identity, but it does not prove that the operator is honest, ethical, competent, or safe.
Traffic analysis
Tor is designed to resist many forms of network surveillance, but it cannot fully eliminate traffic correlation risks against powerful adversaries with broad visibility.
Operational mistakes
The strongest protocol cannot protect a service operator who leaks identifying information through configuration errors, server headers, analytics, reused accounts, payment trails, metadata, or public mistakes.
Onion services and operational security
Operating an onion service safely requires more than enabling Tor. The operator must think carefully about infrastructure, identity, hosting, logs, metadata, software updates, and administrative access.
An onion service may accidentally reveal its location if the same server is also reachable through the public internet, if application errors expose internal addresses, if logs contain sensitive metadata, or if the operator reuses infrastructure tied to their identity.
Operators should treat onion services as part of a full operational security model, not as a single protective switch.
Best practices for users
Users should access onion services through Tor Browser or trusted Tor-aware software.
They should verify important onion addresses from official sources, bookmark verified addresses, and avoid relying on random link lists.
Users should be cautious with downloads, especially documents, scripts, archives, and executable files. Opening downloaded files outside Tor Browser may expose the user’s real IP address or system information.
Users should avoid entering personal information on untrusted onion services. Logging into accounts, reusing usernames, sharing personal details, or making identifiable payments can weaken anonymity.
Users should also understand that Tor Browser security settings matter. Higher security levels can reduce exposure to JavaScript and other active web features, especially on unknown or suspicious onion services.
Best practices for operators
Operators should isolate onion service infrastructure from unrelated systems. They should avoid exposing the same service publicly unless they fully understand the implications.
They should keep Tor, the operating system, the web server, application frameworks, and dependencies updated.
They should avoid unnecessary logging, remove debug pages, protect administrative panels, and prevent server headers or application errors from leaking information.
They should use least privilege for service accounts, restrict administrative access, monitor for abuse, and maintain secure backups.
If the onion service is official, its address should be published on a trusted clearnet domain, signed announcement, or other authoritative channel.
Operators should remember that anonymity is not only technical. It also depends on behavior, infrastructure choices, naming, writing style, payment methods, accounts, and metadata.
Onion services and single onion services
Tor also supports single onion services, a mode designed for services that want the advantages of onion service addressing but do not need to hide the server’s location.
Single onion services can provide better performance, but they trade away service-side location privacy.<ref name="singleonion">Tor Project, Rendezvous Single Onion Services Proposal. https://spec.torproject.org/proposals/260-rend-single-onion.html</ref>
This distinction is important. A regular onion service is designed to protect the server’s location. A single onion service is not intended for the same threat model.
Onion services and denial-of-service resistance
Onion services can be targets of denial-of-service attacks. Attackers may attempt to overload introduction points, force many rendezvous circuits, or exhaust server resources.
Tor has introduced and documented mechanisms such as rate limiting and proof-of-work defenses to help onion service operators reduce certain denial-of-service risks.<ref name="dos">Tor Project Community, Onion service DoS guidelines. https://community.torproject.org/onion-services/advanced/dos/</ref>
Availability remains an important challenge. Privacy-preserving services still need careful capacity planning, monitoring, and defensive configuration.
Onion services in cybersecurity research
Onion services are studied in cybersecurity, privacy, and internet measurement research.
The original Tor design introduced a practical approach to location-hidden services using rendezvous points.<ref name="tor-design">Roger Dingledine, Nick Mathewson, and Paul Syverson, Tor: The Second-Generation Onion Router, USENIX Security Symposium, 2004. https://www.usenix.org/conference/13th-usenix-security-symposium/tor-second-generation-onion-router</ref>
Later research has studied onion service usability, discovery, measurement, security defenses, performance limitations, and abuse patterns. A systematic literature review of Tor hidden services describes the field as an active research area with ongoing challenges in privacy, measurement, security, and misuse prevention.<ref name="slr">D. L. Huete Trujillo et al., Tor Hidden Services: A Systematic Literature Review, Future Internet, 2021. https://www.mdpi.com/2624-800X/1/3/25</ref>
Research is important because onion services are dual-use. They can protect vulnerable users, but they can also be abused. Good research helps improve safety, usability, and accountability without destroying the privacy properties that make the technology valuable.
Common misconceptions
“Onion services are illegal”
This is false. Onion services are a technology. They can be used for legal or illegal purposes, just like encryption, web hosting, cloud storage, or cryptocurrency.
Many onion services support legitimate privacy, journalism, research, and censorship-resistance goals.
“Onion services are the same as the deep web”
This is incorrect. The deep web includes content not indexed by search engines, such as email inboxes, banking portals, academic databases, and private accounts.
Onion services are part of anonymity networks and require Tor-aware software to access.
“A .onion address proves a site is trustworthy”
A .onion address can prove continuity of cryptographic identity, but it does not prove that the operator is honest or safe.
Users must still evaluate the service carefully.
“Tor Browser alone protects everything”
Tor Browser protects traffic that goes through Tor Browser. It does not automatically protect every application on the device.
Other apps may connect directly to the internet unless separately configured.
“Onion services cannot be attacked”
Onion services can still be attacked through web vulnerabilities, server misconfiguration, denial-of-service attempts, phishing, malware, credential theft, or operational mistakes.
Tor protects routing and location privacy, but it does not replace secure engineering.
Ethical and legal considerations
Accessing onion services is not automatically illegal in many jurisdictions, but the legality depends on what the user does and what content or services they interact with.
Users should avoid illegal content, scams, stolen data, malware, exploitation, and harmful services. Researchers should follow ethical guidelines, minimize harm, avoid unnecessary collection of sensitive data, and respect legal boundaries.
Directory operators and educators should present onion services responsibly. They should explain privacy and safety without encouraging reckless browsing or illegal behavior.
Future of onion services
The future of onion services will likely focus on improving usability, authenticity, performance, denial-of-service resistance, and safer discovery.
Major challenges include helping users verify onion addresses, reducing phishing, improving service reliability, supporting legitimate adoption, and defending against abuse without weakening privacy.
As censorship, surveillance, and cyber threats continue to grow, onion services may become more important for organizations that want to offer privacy-preserving access to information.
At the same time, the ecosystem must continue improving user education. Privacy tools are strongest when users understand both their power and their limits.
Conclusion
Onion services are one of the most advanced privacy features of the Tor network. They allow services to be reachable without exposing their server location, while also allowing users to connect without revealing their own IP address to the service.
Their architecture is based on cryptographic identity, service descriptors, introduction points, hidden service directories, Tor circuits, and rendezvous points. This design allows communication to happen inside the Tor network without direct client-server exposure.
Onion services are often misunderstood because of their association with the dark web, but their legitimate uses are significant. They support privacy, free expression, journalism, secure submissions, censorship resistance, research, and safer access to sensitive information.
They are not perfect. They can be slow, difficult to verify, vulnerable to phishing, and weakened by operational mistakes. But when used responsibly, onion services represent a powerful model for privacy-preserving internet publishing.
The central idea is simple and important: a service can be public without exposing where it is hosted, and a user can connect without directly revealing where they are. That is what makes onion services a foundational technology in the modern privacy ecosystem.
See also
- Tor
- Tor Browser
- Tor Links
- Onion Links
- Dark Web
- Deep Web
- Cybersecurity
- Online Privacy
- Encryption
- Censorship Resistance
- Browser Fingerprinting
- Hidden Web
References
<references />