Who Owns Tor Browser? Governance, Open Source and Independent Relays
Tor Browser is developed through the Tor Project and its open-source community. That does not mean one person owns every contribution or controls every relay and onion service. Organizational governance, software licensing and operation of network infrastructure are separate forms of responsibility.

What does owner mean in this question?
| Subject | Relevant relationship | Different from |
|---|---|---|
| The organization | Governance and organizational accountability | Control of every independent service |
| The code | Licensing and contributor rights | A single person writing every component |
| The relays | Infrastructure operated by participants | One centrally owned server fleet |
| An onion site | Its own application and operator | The browser publisher |
A nonprofit is still an accountable organization
Nonprofit status concerns an organizational and legal structure; it does not mean nobody makes decisions or manages resources. Financial reports and governance information help answer organizational questions.
They should not be used as substitutes for reviewing software security, and a software vulnerability should not be described as proof that a relay operator owns the project. The relationships need to remain separate.
Separate the official release from a relay and a destination
The official browser release is software supplied through a maintained publication channel. A relay is infrastructure participating in the network. A destination is an application receiving the browser’s requests. Those roles can be held by different parties, and trust in one does not automatically transfer to the others.
For example, obtaining an authentic browser does not certify the identity of every page it displays. Conversely, a problem with an independent destination does not prove the browser publisher operated that destination. The same distinction helps interpret abuse reports: identify which component and operator the report concerns.
A nonprofit’s organizational documents can clarify governance and resources. Release information helps authenticate software. A publisher’s announcement helps authenticate its service address. Use the source appropriate to the role, rather than asking one ownership label to settle every responsibility in the system.
Open source describes rights and access, not identical roles
A user can inspect or modify code under its applicable license without becoming the official publisher of every version. A fork, a third-party build and an official maintained release can have different update channels and accountability.
For installation, verify the actual publisher and supported download route. A familiar code lineage alone is insufficient to authenticate an app with a copied name or icon.
A browser does not operate every page it displays
Imagine a service asks for a payment or identity document while being viewed in Tor Browser. The browser’s publisher did not necessarily make that request or control the destination.
Evaluate the service operator separately from the client software.
Questions people ask
Sources
Further reading
Glossary
Terms in this guide
Continue learning