Practical orientation for individuals, businesses, developers, and IT teams—not legal or security advice. Follow your organisation’s policy; many employers restrict or monitor work devices.
Privacy tools are practical, legitimate, and increasingly relevant at home and at work. This guide explains what they do, why businesses should take privacy seriously, and what developers and security teams need to know—including enough detail for allow-list conversations.
For everyone
Your browsing leaves a trail — Sites, networks, and Wi‑Fi operators can see where you go and link sessions together. Privacy tools limit what is collected and how easily it is tied back to you.
Tracking follows you across sites — Third-party cookies, analytics, and embedded widgets build profiles for ads and analytics. A privacy-focused browser blocks or reduces much of that by default.
Work devices are not personal space — Employers may monitor corporate equipment and traffic. Personal privacy tools on work laptops can violate policy—know the rules before you install anything.
Breaches and over-collection hurt trust — For businesses, sloppy data handling damages reputation and invites regulatory scrutiny. Privacy posture is risk reduction, not a nice-to-have.
Small changes add up — Switching browser, tightening search defaults, or using Tor for specific tasks does not require rebuilding your digital life. Start with one habit and expand.
When you browse the web, several parties can observe what you do: the sites you visit, your network provider, whoever runs the Wi‑Fi you are on, and—on a work device—your employer’s security tooling. Privacy tools reduce how much of your activity is visible or how easily it can be linked to you.
Privacy is not the same as anonymity. A privacy-focused browser limits tracking and data collection. Anonymity tools such as Tor (The Onion Router) go further by trying to hide who is connecting. This guide covers both, in that order.
For most people, the first practical step is browser choice. Everything else—virtual private networks (VPNs), Tor, messaging apps—builds on that foundation.
Reusing passwords across sites bridges privacy and security risks—see our password management guide for credential hygiene basics.
For businesses — treat privacy as a priority
Trust is a product feature — Customers, partners, and procurement increasingly ask what you collect, where data lives, and which subprocessors you use. Privacy posture affects deals, not just compliance tick-boxes. This guide complements—not replaces—compliance-aware engineering work on the systems you ship.
Regulation is a design constraint, not a late audit — EU and UK frameworks (for example the General Data Protection Regulation (GDPR), UK GDPR, and emerging AI rules) reward data protection by design. Engineering teams need room to build that way from the start. This is engineering alignment—not legal advice.
Incidents are expensive in money and reputation — Breaches, over-collection, and sloppy retention destroy trust faster than features create it. Privacy investment is risk reduction.
Workplace policy should be deliberate — Blocking every privacy browser by default, while allowing unchecked trackers, sends the wrong signal. Policies should distinguish approved work tools, personal use on personal devices, and clear rules for corporate equipment.
Recommend sensible defaults for staff — If the organisation cares about privacy, say so: supported browsers, VPN guidance where appropriate, and training on phishing and data handling. The tools in this guide are reputable options—not shadow-IT workarounds.
What you ship reflects your values — B2B vendors who minimise data, document flows, and test in privacy-hardened browsers are easier for enterprise customers to adopt. Privacy-aware engineering is a competitive advantage.
Cross-border and vendor due diligence — Where data goes—UK, EU, US clouds, analytics SDKs—matters to customers and regulators. Treating privacy as a priority means asking those questions before launch.
Other privacy-oriented browsers exist—hardened Firefox profiles, LibreWolf, DuckDuckGo Browser, and more. We are not claiming this is an exhaustive list.
We highlight Mullvad Browser and Brave because they are maintained, reputable, free starting points on two different engines: Firefox and Chromium. Pick the one that fits how you already browse.
If you prefer Firefox-style browsing, start with Mullvad Browser. If you prefer Chrome-style browsing and extensions, start with Brave. Both are a step up from a default browser for everyday privacy.
You want Firefox-style browsing with Tor Project–hardened defaults and no Chromium.
Mullvad Browser is a privacy-focused web browser built on Firefox, developed in collaboration with the Tor Project. It ships with strong anti-fingerprinting settings and does not require an account.
It is a good default if you prefer to stay off the Chromium ecosystem while still getting a maintained, everyday browser.
Mullvad also offers a separate VPN product; the browser works without it, but the two can be used together if you choose.
You want a Chrome-like experience, extension compatibility, and built-in tracker blocking.
Brave is a privacy-oriented browser built on Chromium. Shields block many ads and trackers by default, while keeping a familiar tab-and-extensions workflow for people coming from Chrome.
Optional features such as Rewards can be ignored or disabled; the core browser is free and does not require an account for basic use.
It is widely used and documented, which can make workplace conversations about allow-listing more straightforward than niche forks.
You need strong anonymity on the web—not just fewer trackers—and understand the trade-offs.
Tor routes your traffic through a network of volunteer relays, wrapping it in layers of encryption. The entry relay sees your network address but not where you are going; the exit relay sees the destination site but not who you are. Logging into personal accounts can still identify you.
Tor Browser is the supported way to browse the web over Tor. It is tuned to reduce fingerprinting mistakes that would weaken anonymity.
Tor is not a replacement for a daily work browser: it is slower, some sites block Tor exits, and many employers restrict it on policy grounds. Use it when anonymity matters and your context allows it.
Private search (UK & EU)
Search engines see what you look for. Mainstream options such as Google log queries, link them to accounts and devices over time, and use that history for ads and personalisation. If you are in the UK or EU/EEA, switching search provider is a practical next step after browser choice.
Other privacy-oriented search engines exist—DuckDuckGo, Startpage, Ecosia with privacy settings, and more. We are not claiming this is an exhaustive list. Outside the UK and EU/EEA, a local privacy search option may be more practical.
We highlight Qwant for UK and EU readers because it is developed in France, aligned with GDPR and CNIL guidance, and designed not to track searches or build advertising profiles from your query history. Qwant may query partners to enrich some results and applies pseudonymisation and data limitation per its privacy policy—a materially different model from profile-based search and US-centric data handling.
You are in the UK or EU/EEA and want everyday web search without Google-style profiling from your query history.
Qwant is a French search engine for web, news, maps, and related queries. It does not use advertising trackers to build a profile from what you search, and results are not tailored to a long-term search history.
For UK and EU users, Qwant operates under European law with infrastructure in the EU—relevant if you care where search-related data is handled and how it is protected under GDPR and UK GDPR expectations.
Set Qwant as your default search in Mullvad Browser, Brave, or your system browser settings. This is privacy, not anonymity: sites you click through to, and your employer on a work device, may still see activity.
You have seen what these tools do for browsing. This section covers building, testing, and shipping software in a privacy-aware way.
Mullvad Browser
Gecko with Tor Project hardening: Resist Fingerprinting (RFP), minimal telemetry. Compare with rolling your own user.js or LibreWolf if you want to understand the trade-offs.
WebRTC and leak testing: a hardened browser matters when you debug auth flows or real-time apps—verify what your app exposes when trackers are blocked.
Standard Firefox DevTools: test how your product behaves when third-party cookies and trackers are blocked by default.
Smaller extension ecosystem than Chromium—relevant if your workflow depends on Chrome-only extensions.
Brave
Full Chromium DevTools; Shields can be toggled per site when you test analytics or third-party embeds.
Fingerprinting protections differ from stock Chrome—do not assume navigator or canvas behaviour matches Chromium exactly.
Optional Tor window is not a Tor Browser replacement; know what it isolates and what it does not.
Document which browser binary your team uses—IT policies often say “Chrome” when they mean any Chromium derivative.
Tor
Tor Browser exposes a local SOCKSproxy (see Tor Project docs for the current port—often 9150 on localhost). Route CLI tools for privacy-sensitive checks; verify the port in your install.
Onion services (.onion) hide server location; relevant for infrastructure work, not typical SaaS patterns.
Do not roll your own Tor client—misconfiguration leaks metadata. Use Tor Browser or the documented tor daemon APIs.
If your product claims “private” or “anonymous”, test with and without Tor and log what your server actually sees: IP, headers, TLS fingerprint, timing.
Tor control port automation is documented for integration work—treat it as a production-sensitive surface.
If you build software
Threat model in one minute — List assets (user data), adversaries (trackers, network observers, compromised dependencies), and mitigations (browser hardening, encryption, minimal collection). Privacy-by-design means deciding this before you ship—not after an audit.
Fingerprinting you may be shipping — Canvas, WebGL, font enumeration, navigator APIs, third-party analytics SDKs, and embedded widgets can identify users. Privacy browsers block or randomise many of these; your app should still work when they do.
Dependencies and supply chain — Audit npm, PyPI, and other packages for phone-home behaviour. Your privacy policy should match what your code actually sends.
Local dev hygiene — Separate work and personal browser profiles. Do not debug with production PII on unmanaged devices. Use isolated browsers or containers when testing authentication.
What to document for enterprise customers — If you sell B2B software, list domains your app calls, data flows, retention, and which browsers you test. That helps security teams allow-list your product alongside privacy browsers.
Search queries are not private by default — Do not put secrets, tokens, or personal data in URL query strings—search engines, referrers, and server logs may retain them. If your product includes site search, treat queries like any other personal data flow.
Example: check connectivity through Tor Browser's local SOCKS proxy (verify the port in your install):
These tools are legitimate privacy products. Blocks are often policy-driven or based on outdated allow-lists. Verify endpoints against vendor documentation before production changes.
Mullvad Browser
Firefox / Gecko base; updates via Mullvad’s distribution channels. Verify current endpoints in Mullvad’s documentation before production allow-lists.
Typical domains: mullvad.net and vendor-documented update/CDN hosts.
Standard desktop installer—not a browser extension masquerading as admin tooling.
Often blocked because it is uncommon on legacy allow-lists or confused with VPN-only tooling. Prefer official installers from mullvad.net.
Brave
Chromium base; component and update services similar to other Chromium derivatives. Brave publishes component URLs—verify before allow-listing.
Typical domains: brave.com and Brave-documented update/component hosts.
Treat like Chromium for patch cadence; review optional features (Rewards, Widevine) against policy.
Generic “block non-Chrome Chromium” rules often catch Brave—document the exact binary if policy permits it.
Tor Browser
Traffic pattern: TLS to directory authorities; OR protocol connections to guard relays—distinct from ordinary HTTPS browsing.
Local SOCKS: Tor Browser commonly documents port 9150; standalone tor daemon often uses 9050. Confirm in Tor Project docs for your version.
Downloads and docs: torproject.org; directory authority hostnames are published by the Tor Project.
Bridges and pluggable transports exist where direct Tor is blocked.
Many enterprises block Tor on policy grounds (abuse, exfiltration, compliance). Whitelisting is an organisational decision—not a recommendation here.
Tor is anonymity-focused, not a VPN replacement for corporate SaaS login workflows.
Qwant
HTTPS search traffic to qwant.com and vendor-documented API/CDN hosts. Verify current endpoints in Qwant’s documentation before production allow-lists.
Typical domains: qwant.com, about.qwant.com, and Qwant-documented service hosts.
Distinct from direct Google or Bing use—policy teams may need a separate allow rule if privacy search is permitted.
No Google account sync; results may still call partner services with pseudonymisation per Qwant’s privacy policy.
Enterprise quick reference
Tool
Category
Primary domains
Base engine
Allow-list notes
Mullvad Browser
Privacy browser
mullvad.net (+ vendor update hosts)
Firefox / Gecko
Firefox-family; no Google sync
Brave
Privacy browser
brave.com (+ Brave update/component hosts)
Chromium
Treat like Chromium for updates; review optional features
Tor Browser
Anonymity browser
torproject.org
Firefox + Tor
Relay traffic; policy decision; bridges if permitted
Qwant
Search engine
qwant.com (+ vendor service hosts)
Web search
HTTPS to Qwant endpoints; distinct from Google/Bing direct use