If you searched for how to enable JavaScript in Tor Browser, here's the short answer that surprises most people: it's almost certainly already enabled. Tor Browser ships with JavaScript switched on. If a site is broken and you haven't changed anything, JavaScript probably isn't the culprit — and if you did change something, the fix is a single setting. The steps are below. But the setting you'd be changing exists for a reason, and it's worth thirty seconds to understand what you're trading before you trade it.
Why Tor Browser treats JavaScript as a dial, not a switch
Tor Browser's job is to make you indistinguishable from every other Tor Browser user. Every install reports the same fonts, the same screen dimensions, the same hardware story — a crowd of identical browsers that fingerprinting can't tell apart. JavaScript complicates that job in two distinct ways.
The first is fingerprinting surface. JavaScript is the richest source of browser-distinguishing signals there is — canvas rendering quirks, WebGL parameters, font probing, fine-grained timing. Tor Browser neutralises a great deal of this even with JavaScript running, through uniform configuration and defences such as letterboxing and canvas-access prompts. That's why it can afford to leave JavaScript on by default: turning it off for everyone would break most of the web and drive people to less safe browsers.
The second reason is the bigger one: exploit surface. A JavaScript engine is a large, complex piece of software, and historically it has been the delivery vehicle for the attacks that actually de-anonymised Tor users — most famously the 2013 Freedom Hosting operation, which used a JavaScript-delivered Firefox exploit against visitors to certain onion services. No fingerprinting defence helps against code execution. The only defence is not running the code.
That's what the Security Level setting really is: a dial for how much of that surface you expose. Standard enables everything. Safer keeps JavaScript but hardens it — disables the just-in-time compiler, restricts some fonts and media. Safest disables JavaScript everywhere, along with most of the machinery attacks have historically ridden in on. Higher levels break more sites; that's not a bug, it's the price being stated honestly.
The steps
If a site you trust genuinely needs JavaScript and you're at Safest:
- Click the shield icon to the right of the address bar.
- Click Settings… — this opens the Security Level section of Tor Browser's preferences.
- Choose Standard or Safer.
- Reload the page.
Two things not to do. Don't grant per-site exceptions through the NoScript extension's own
menus, and don't touch about:config — a hand-tuned configuration makes your browser
different from every other Tor Browser, which chips away at the crowd you're hiding in. The
Security Level is the supported dial; use it, and set it back when you're done with the site
that needed it.
The honest framing is that this isn't "fixing" anything — it's choosing compatibility over a harder security posture, for a session, with your eyes open. For most browsing at Standard, that's a reasonable choice; it's the default for a reason. The people who deliberately run Safest usually have a threat model that justifies broken sites, and if that's you, be reluctant to lower it for any site you don't have a strong reason to trust.
One last note, since plenty of people land on this page from our own site: snapWONDERS' tools need JavaScript for a specific reason, not a generic one — they run on the TUS resumable-upload protocol, which survives a Tor circuit rotating or an I2P tunnel rebuilding mid-transfer by resuming from the last confirmed chunk instead of failing outright. That's exactly the kind of connection Tor and I2P routinely produce, so the trade-off runs in your favour here rather than against it. Every script is self-hosted from the same onion or eepsite address you're already on — no CDN calls, no third-party requests — and the site runs at Tor Browser's default Standard level, no overrides needed. Full detail: What's Changing.
