How to download Tor Browser safely: official sources, checksums and mirror traps
tor browser is the front door to everything in this scene, which makes its download page one of the most targeted surfaces on the internet. attackers do not need to break tor's cryptography - they just need you to install their version instead of the real one. the defense is a short, boring procedure: get the file from a channel you decided on in advance, then verify the file itself. here is exactly how.
rule zero: decide the source before you need it
most compromises happen in the moment of impatience: you are on a café laptop, you search "tor browser", and you click the first result or a sponsored ad. seo-poisoned pages and paid placements have repeatedly ranked above the official site with convincing clones underneath. the fix is procedural, not technical: the only acceptable sources are the tor project's own domain and links that originate from it.
- primary: https://www.torproject.org/download/ - the project's own site, served over https
- secondary: official mirrors linked directly from that page when the main site is unreachable
- android: tor browser on google play under the tor project's publisher name, or the signed apk from the same site
- ios: onion browser, the project-endorsed ios option - not the dozens of lookalikes
everything else - download portals, tech blog reuploads, telegram attachments, "faster mirrors" offered in comments - is untrusted by default, no matter how helpful it claims to be.
why https alone is not enough
https authenticates the connection between you and whatever server answered. it cannot tell you whether that server is the one you meant to reach. dns poisoning, spoofed domains with visually similar names, and compromised ad networks all deliver valid https connections to the wrong place. a padlock certifies encryption in transit, not the honesty of the far end - we unpacked this distinction for onion sites specifically in our coverage of certificates on .onion services.
that gap is closed by verifying the downloaded file itself against values published by the developer. file-level checks travel with the bits; they work regardless of how many hops or proxies the file passed through.
verification method one: the sha-256 checksum
- download the installer for your platform from the official site, and also grab the checksums file the project publishes alongside releases.
- compute the hash of your downloaded file. on windows: certutil -hashfile file.exe sha256. on macos/linux: shasum -a 256 or sha256sum. or drop the file into our browser-based sha-256 checksum tool, which hashes locally without uploading.
- compare the computed hash against the published value, character by character. hashes are case-insensitive but otherwise unforgiving: one differing character means the file is not what the project shipped.
- if they match, proceed. if they differ, delete the file, figure out where the download actually came from, and start again from the official site.
verification method two: the openpgp signature
checksums answer "is this file intact"; signatures answer "did the tor developers approve it". the project signs its releases with a gnupg key whose fingerprint is published on its site. import that key once, verify its fingerprint, and thereafter every release can be confirmed with gpg --verify tor-browser.asc tor-browser.exe. the complete procedure - including reading failure messages honestly - is in our signature verification guide, so we will not duplicate it here.
run both checks when you can. they fail in complementary ways: a swapped file with an intact size fails the hash, while a sophisticated attacker who somehow obtained a validly-signed old build fails your expectation of the current version number, which the signature metadata reveals.
the mirror trap
mirrors deserve special mention because they sound legitimate and sometimes are. the tor project operates official mirrors precisely so censored users can still fetch the browser, and those mirrors inherit trust from being listed on the official site. unofficial mirrors have no such chain: hosting a trojanized tor installer is one of the oldest tricks in the book, because victims arrive pre-filtered - people who want anonymity are exactly the targets.
the same economics drive fake mirror lists for markets, which we analyzed when covering mirror wars and official link lists. the lesson generalizes: a mirror is only as trustworthy as the page that referred you to it. if that page is a stranger's post, the mirror is a stranger's server.
after installation
- leave the security level on safest until a site genuinely needs more; the default disables scripts that deanonymization exploits love.
- do not install extensions beyond what ships with the browser - addons are a fingerprinting and leakage vector.
- keep the browser updated through its built-in updater, which preserves your settings and verifies updates internally.
- remember the browser anonymizes traffic, not your behavior: logging into personal accounts inside tor undoes much of the point. baseline device hygiene still applies - see our device security notes.
if the network itself is blocked
some networks and countries block access to tor, which is distinct from blocking the download. the official answer is bridges - unlisted entry relays - configured from within the browser's connection settings, with pluggable transports like obfs4 designed for exactly this. acquire bridges through the official channels described in our bridge guide rather than third-party lists, for the same provenance reasons as everything above: trust flows from the source, never from convenience.
total cost of the careful path: five minutes and one terminal command or one browser tab. total cost of the careless path: discoverable only after the fact. choose accordingly.
when you cannot reach the site at all: gettor and offline copies
the tor project runs a service called gettor precisely for users who cannot open torproject.org: you email gettor@torproject.org from any address (or message it on selected platforms) and it replies with download links for your operating system. the links point to officially hosted files, so the same checksum verification applies once you have them. this route exists because censors block the website, not because the project endorses random reuploads - keep that distinction in mind when someone offers a "gettor alternative".
another underused channel is copying from a machine that already has a verified copy. tor browser is portable by design: a folder copied from a verified installation on another computer works identically, provided both machines are trusted and the copy travels on media you control. for families or small teams, one verified master copy distributed internally beats every individual rolling their own download dice behind restrictive networks.
android specifics worth knowing
on android, prefer the google play listing published under the tor project's own developer name - play store signatures are checked automatically at install time, which removes an entire failure mode. if you sideload instead, fetch the apk from the official site and verify its signing key fingerprint as documented there before installing; android will warn about unknown sources, which is expected. avoid third-party apk aggregators entirely: repackaged tor apks with an added SDK have appeared on such sites more than once, and the modification is invisible without signature checking.
- check the publisher name on play listings, not just the app icon and name
- official ios support lives in onion browser, developed with the guardian project - anything else claiming to be "tor for iphone" in the app store is riding the brand
- updates should arrive through the same channel as the original install; an app demanding manual updates from its own website is describing its own phishing flow
updating versus downloading fresh
once installed, the browser updates itself through the built-in updater, which verifies update packages internally against the release signing key. this is safe and convenient, and you should not disable it. but the updater does not rescue a bad origin: if your first install came from a trojanized mirror, updating faithfully preserves the compromise. verification is therefore not optional even for people who "always keep updated" - it is the check that makes every future update meaningful.
a clean reinstall cycle is also worth doing occasionally: download the current version fresh from the official site, verify it, and replace your existing installation. it clears accumulated state, takes ten minutes, and doubles as a rehearsal of the full procedure while nothing is at stake.
what a trojanized build actually changes
it helps to know what attackers do to modified builds, because none of it is visible in normal use. typical modifications ship the browser with javascript enabled despite the safest default, preconfigure a proxy or log destination alongside tor, bundle an "update helper" that phones home, or swap out the bundled noscript defaults. everything looks normal; bookmarks load; pages render. the tell never appears on screen - it appears in network connections you cannot see without tooling.
this asymmetry is why the security community repeats the same advice mechanically: source first, hash second, signature third. no amount of post-install vigilance compensates for an installer you did not verify, because the malicious behavior was designed to be unobservable from the inside. the five minutes of hashing with our checksum tool is genuinely the whole defense.