Tor Browser Security Slider in 2026: Safer-Safest Settings and What They Actually Protect Against

The Tor Browser security slider is one of those features that looks simple on the surface: three levels — Standard, Safer, Safest — and you drag between them depending on how sketchy the site you’re visiting feels. For years, the community has treated it as a reliable dial for risk. But in mid-2025, a flaw was publicly demonstrated that should change how you treat that slider, and it has direct implications for anyone who relies on tor hidden services for research or operational security.

Here’s the short version: not all protections advertised by the slider are actually engaged until you fully restart the browser. If you switch from Standard to Safer mid-session because you just clicked a link to an onion service you don’t trust, you may not get the protection you think you’re getting. The Tor Project is aware of the issue, and there are fixes on the roadmap, but as of the latest stable releases, the onus is still on you to know how the slider actually behaves.

The Flaw: JIT Still Runs in “Safer” Mode Until Restart

The issue was first reported anonymously to Privacy Guides and confirmed on Tor Browser 14.5.1 (and Mullvad Browser 14.5.1) on macOS. The test is brutally simple: run a JavaScript benchmark like JetStream 2.2, which relies on Just-in-Time (JIT) compilation for performance. The “Safer” security level is supposed to disable JIT entirely — it’s a known attack vector in modern browsers. But when you switch to Safer and re-run the benchmark, the performance is virtually identical to the Standard run. That means JIT is still active, and the protections you expected are not in place.

After a full restart, re-running the benchmark shows drastically lower performance — exactly what you’d expect with JIT properly disabled. The problem is that there is no visible indicator in the UI that anything is different, and no prompt to restart. The browser just sits there, looking like it’s protecting you, while the JavaScript engine is still fully weaponized against you.

I would normally be skeptical of a finding like this — sometimes “we tested it and it’s broken” turns out to be a misread of the prefs. But the demonstration is solid, and the Tor Project’s response confirms the underlying issue. Their statement acknowledges the problem, says it’s being tracked in the GitLab issue tracker (issue 42572), and mentions that they are exploring broader improvements to the security level system, including aligning it more closely with the updated threat model and possibly delegating more of the back-end work to NoScript.

What Safest Mode Does (and What We Don’t Know)

The Safest mode is a different beast. It disables JavaScript entirely, so the JIT test doesn’t apply — there’s no JavaScript running at all, so there’s no JIT to leave enabled. But the Privacy Guides team explicitly notes that they have not tested or verified the full extent of the security features that require a browser restart in Safest mode. They tested JIT because it was the easiest feature to verify. There could be other prefs — font disabling, WebGL limits, canvas poisoning — that behave similarly.

That should give you pause. If the known issue is that prefs don’t apply until restart, and we only tested one of them, the honest position is that all slider changes should be followed by a full restart. That’s the safe assumption. The recommendation from the researchers is categorical: always restart after changing the setting, regardless of whether you’re switching to Safer or Safest.

The Technical Reason: Some Prefs Are Restart-Only

If you dig into the discussion around the flaw, you find the root cause. Some of the prefs that the slider changes require a browser restart to take effect. Others don’t. The state of those restart-dependent prefs when you open the browser determines what you actually get when you move the slider. This introduces entropy that wasn’t designed for, and it misleads users about their security posture at a given moment.

There’s also a fingerprinting angle here, which is worth stating plainly: some slider prefs that require a restart and some that don’t are fingerprintable. That means a malicious site — or a deanonymization operation run by law enforcement — could potentially detect that your browser is in an inconsistent state. You think you’re running at Safer, but the browser is leaking signals that say otherwise.

The Tor Project’s proposed fix — forcing a restart after a slider change — would solve the technical problem, but it becomes a pain point in practice. I understand the hesitation. But from a user perspective, a forced restart is a small price to pay for not having a false sense of security.

Why This Matters for Tails Users

There’s a specific population for which this flaw is worst: Tails users. If you’re running Tails from a USB stick, you’re probably changing the slider each session depending on what you’re doing. And Tails is a live system — there’s no persistent state between boots, so you’re starting fresh every time. The default behavior in Tails is to boot into Tor Browser at a particular security level. If you change it mid-session, the restart requirement is especially easy to miss, because the whole point of Tails is that you reboot to wipe state.

The discussion around this issue explicitly notes that Tails users are most likely to be changing the slider each start, and most likely to not be restarting the browser after a change. That’s a dangerous combination for anyone using Tails for tor hidden services research.

A Dangerous Combination: Slider Misconceptions and JavaScript Attacks

To understand why this flaw is more than a theoretical annoyance, you have to look at how JavaScript is actually used against Tor users. The Tor Browser documentation warns you not to maximize your window. Why? Because JavaScript can measure your screen’s exact resolution, and that data point, combined with system fonts and time zones, creates a unique browser fingerprint. It sounds paranoid until you remember that law enforcement has deployed malicious JavaScript on dark web forums specifically to bypass Tor and ping a user’s real router, revealing their actual IP address.

That’s why the “Safest” setting exists — it disables JavaScript globally. The conventional wisdom is that if you’re done with your business on a trusted marketplace and you’re about to click around on unknown onion links, you’d drop the slider to Safest and proceed. If that change doesn’t actually apply until you restart, you’re exposing yourself to exactly the attack vector you were trying to close.

The mitigation is simple but requires discipline: change the slider, then fully restart the Tor Browser, and only then proceed to the sketchy site. Not “close the tab and open a new one.” Not “navigate to a new URL.” Full restart. Kill the process, start it again.

The Practical Workflow for Security-Conscious Users

Assuming you have already done a tor browser download and have a working tor browser bundle installed, here is the workflow I recommend for anyone who needs to move between trust levels in a single session:

• Plan your session around restarts. If you know you’ll need to visit an untrusted .onion after doing business on a trusted market, do the trusted stuff first, then change the slider, restart, and move to the next phase. Don’t try to do it in one continuous session.
• Restart after every slider change. Even if you’re only moving from Standard to Safer. Even if you’re moving from Safer to Safest. The cost of a restart is seconds; the cost of a missed pref is potentially your identity.
• Verify with a benchmark if you’re paranoid. The JetStream test is public and easy to run. If you switch to Safer and the benchmark still runs fast, you know you’re not protected. This is a useful hack for verifying that your browser state is what you think it is. Just remember that JetStream is only a proxy — it tests JIT, not every protection.
• Keep the default window size. The slider is not the only protection you have. Never maximize the Tor Browser window. Keep it at the default size so you blend in with the rest of the Tor user base. Fingerprinting is a numbers game; don’t make yourself stand out.

What’s Coming in Future Releases

The Tor Project has acknowledged the issue publicly. The statement from May 2025 says the problem is tracked and being actively addressed, and that improvements may be part of the upcoming 15.0 release cycle. They’re exploring adding a restart prompt, but they’re also looking at the bigger picture: aligning the security level system more closely with the browser’s updated threat model, and possibly delegating more of the back-end to NoScript for additional flexibility.

That last point is interesting. NoScript is the underlying technology that enforces a lot of the JavaScript blocking anyway. If Tor Browser moves more of the slider logic into NoScript’s real-time enforcement, the restart requirement could disappear entirely. But that’s a future fix, not a current one. As of today, you should assume the flaw is present in your browser.

The Bottom Line

The security slider is not a real-time control. It’s a configuration tool that requires a restart to fully apply. The Tor Browser UI doesn’t tell you that, and the documentation doesn’t either. That’s a design failure that creates a false sense of security for users who think they’re protected when they’re not.

For anyone doing serious work with tor hidden services, this is not a minor quibble. The difference between JIT-on and JIT-off is the difference between a browser that’s resistant to a class of exploits and a browser that’s exposed to them. The fix is free and immediate: restart after every slider change. Make it a habit. Assume the slider is lying to you until you’ve confirmed the browser is in the state you want. And if you’re running Tails, treat every slider change as a signal to reboot, not just to restart the browser.

The Tor Project will eventually fix this — they’ve said so publicly. But until then, the burden is on you to know how your tools actually behave, not just how they advertise themselves.