Userscript managers in 2026: what Manifest V3 actually changed

What Manifest V3 actually changed

Chrome completed its Manifest V2 phase-out through 2025, force-disabling extensions that had not migrated. Most categories adapted with some grumbling about blocking rules. Userscript managers had a harder problem: their entire function is to fetch code a user chose and run it in a page, and restricting exactly that was one of MV3's design goals.

The resolution was a dedicated userScripts API, available from Chrome 120 onwards for MV3 extensions. An extension declares the userScripts permission alongside host permissions for the sites it will touch, and registers scripts through that API rather than injecting them itself.

So the category survived. Both major managers ship MV3 builds and both run on Chrome, Edge and Opera today. The part that trips people up is not the migration, it is the consent gate that came with it.

The toggle nobody tells you about

Chrome will not hand the userScripts API to an extension unless the person using the browser has explicitly allowed it. Reasonable, and the reason this is worth an article is that the switch has moved.

• Chrome before 138. The user had to enable Developer Mode at chrome://extensions. A browser-wide setting, with a persistent warning attached, to permit one extension to do the thing it was installed for.
• Chrome 138 and later. A per-extension Allow User Scripts toggle on that extension's own details page. Narrower and better: it grants the capability to one extension rather than putting the whole browser into a developer posture.

The behaviour when it is off also changed, and this is the detail that produces the support threads. Chrome's own documentation notes that from 138, with the toggle disabled, browser.userScripts is undefined rather than throwing. The manager loads. Its dashboard opens. Your scripts are listed, enabled, apparently fine. Nothing runs, and nothing says why.

If you have installed a userscript manager and your scripts are not firing, check that toggle before you debug anything else. It is the single most common cause and it produces no error message.

Tampermonkey against Violentmonkey, on the things that differ

Tampermonkey and Violentmonkey account for most of the installed base, and for most of the argument. They are more alike than either community suggests: both support the older synchronous GM_ functions and the newer promise-based GM. ones, both run on Chrome, Firefox, Edge and Opera, both sync, both export.

The differences that would actually change a decision:

• Licence. Violentmonkey is open source under an MIT-style licence: the change history is public and anyone can file a pull request against a behaviour they dislike. Tampermonkey is closed source, so using it means trusting the vendor, because the code cannot be independently audited. For an extension that by design can read and rewrite every page you visit, some people will stop reading here.
• Safari. Tampermonkey has an official Safari build, sold through the App Store. Violentmonkey has none. On Safari this is not a comparison.
• The dashboard. Tampermonkey's is the fuller one, with syntax highlighting, a diff view for script updates and a searchable list. Violentmonkey is leaner and will happily hand editing to your own editor. Which is better depends entirely on whether you write scripts or only install them.
• New APIs. Violentmonkey has generally been quicker to adopt new GM. functions.
• Android. Violentmonkey is available on Firefox for Android through Mozilla's add-on collection. Tampermonkey's mobile story is thinner.

The sync trap, which costs people their settings

Both managers sync scripts to a cloud provider. Tampermonkey covers Google Drive, Dropbox, OneDrive, WebDAV and local files; Violentmonkey covers Google Drive, OneDrive, WebDAV and a generic REST endpoint. Both export a zip.

What neither carries across is the data your scripts have stored through GM_setValue. Your scripts arrive on the new machine; their accumulated state does not. For a script that only restyles a page this is invisible. For one that holds an API key, a whitelist, a counter or anything you configured once and forgot, it is a silent reset on the far side of a migration you thought had worked.

If your scripts hold state worth keeping, export it deliberately before you move rather than assuming sync covered it.

The recommendation people do not want

Firefox has not forced the same timetable on the old extension APIs, so userscript managers behave more predictably there than on Chrome. No consent toggle that silently disables the API, no per-version change to where that toggle lives.

That is a real answer to "which userscript manager should I use", and it is about the browser rather than the manager. If userscripts are how you use the web, running them somewhere the platform is not actively narrowing them is the choice with the fewest future surprises. If you are on Chrome for other reasons, both managers work; you simply have a switch to find first.

The other managers, and when one of them is the answer

The big two take most of the attention. Four others are worth knowing, because each is the right answer in a situation the big two handle badly.

• Greasemonkey. The original, and Firefox only. It is still maintained and still works, and it carries the longest history of any manager here. Its script API diverged from the Tampermonkey-flavoured norm years ago, so a script written against modern GM. conventions may need adjusting. Choose it if you are on Firefox and value the lineage; choose Violentmonkey if you want the widest script compatibility on the same browser.
• FireMonkey. Also Firefox, and the distinguishing feature is that it manages user styles as well as user scripts in one extension. If half of what you install is CSS rather than JavaScript, that consolidation is the reason to look.
• Userscripts for Safari. An open-source Safari extension, and the usual recommendation for people who want userscripts on Safari without paying for Tampermonkey's App Store build.
• Stay. A newer Safari manager whose selling point is compatibility: it runs its own native scripts and also accepts scripts written for Tampermonkey and Violentmonkey, which is the practical problem on Safari, where the library was written for browsers you are not using.

The pattern is worth naming. On Chrome the question is which of two managers to run. On Firefox you have genuine choice and the platform is not fighting you. On Safari the question is which compatibility compromise you prefer.

What actually breaks under MV3, beyond the toggle

The consent switch is the one that catches everyone, but it is not the only behavioural change. These are the ones that show up as "this script used to work".

Background requests. MV3 replaced persistent background pages with service workers, and XMLHttpRequest is not available in a service worker. Managers moved to fetch underneath. Most scripts never notice, because they call GM_xmlhttpRequest rather than the browser API directly, but the translation is not perfectly lossless: reports against MV3 builds include FormData being form-encoded when it was not before, and binary responses being handled poorly or not at all. If a script uploads files or downloads an image as a blob, that is where to look first.

Content Security Policy. A page with a strict CSP blocks inline script, and that is the whole point of a CSP. Userscript managers run your code in an isolated world where the page's policy does not apply, which is why a userscript can still do things the page itself forbids. Where this bites is the cross-boundary work: touching the page's own window through unsafeWindow, or injecting elements the policy rejects.

unsafeWindow. Still available, still the correct tool when a script genuinely must reach the page's own JavaScript context, and still the sharpest object in the drawer. Reaching into the page's global scope deliberately steps outside the isolation that separates your script from the site's, which is the same boundary that stops a hostile page reaching back. Treat any script that uses it as one you need to have read.

The part that deserves more attention than the comparison

A userscript manager is the most privileged thing most people install in a browser. It can read and rewrite every page you visit, including your bank, your email and your employer's internal tools. The extension itself is not the risk; the scripts are, and they come from wherever you found them.

Three habits are worth more than any choice between managers.

Read what you install. A userscript is plain JavaScript and the manager shows it to you before it runs. You do not need to understand every line to spot the shape of a problem: a script that restyles a page should not contain a URL you do not recognise, and a script that hides adverts has no reason to read document.cookie or post anything anywhere.

Watch the @match lines. The header declares which sites the script runs on. @match *://*/* means every page on the internet, which is occasionally justified and usually laziness. Narrow it yourself if the author did not; the managers let you edit the header of an installed script.

Understand auto-update. Scripts update from the URL in their @updateURL, which means the code you read is not necessarily the code that will be running next week. That is convenient, and it is also a supply chain with one maintainer and no review. For anything with broad matches, consider turning automatic updates off and reading the diff yourself. Tampermonkey's dashboard shows a diff view for exactly this.

None of this is an argument against userscripts. It is an argument for treating them as code you are choosing to run with your own privileges, because that is what they are.

Choosing, in one paragraph each

You are on Firefox. Violentmonkey, unless you specifically want user styles managed in the same place, in which case FireMonkey. You get the widest script compatibility and a platform that is not narrowing the APIs underneath you.

You are on Chrome or Edge and you mostly install other people’s scripts. Either works. Violentmonkey if the open-source licence matters to you, Tampermonkey if you want the richer dashboard and the diff view on updates. Find the Allow User Scripts toggle first, whichever you pick.

You write your own scripts. Tampermonkey's editor, diff view and searchable list do more for you, and its documentation is the more complete of the two. Violentmonkey pairs better with an external editor if that is how you already work.

You are on Safari. Tampermonkey if you will pay for the App Store build and want the name everyone writes scripts against. Userscripts if you want an open-source option. Stay if your existing library was written for Tampermonkey or Violentmonkey and you need it to keep working.

Your scripts are load-bearing. Run them on Firefox. Not because Chrome's managers are bad, but because the consent gate has already moved once between Chrome versions and the direction of travel on running user-supplied code in Chrome has been consistent for years.

Questions people ask

Does Tampermonkey still work on Chrome in 2026?

Yes. Tampermonkey ships a Manifest V3 build and runs on Chrome. You must enable the "Allow User Scripts" toggle on its details page in Chrome 138 or later, or Developer Mode in earlier versions, before your scripts will run.

Why are my userscripts not running after installing a manager?

Almost always the Chrome consent toggle. From Chrome 138, if "Allow User Scripts" is off for that extension, the userScripts API is undefined rather than raising an error, so the manager appears installed and healthy while nothing executes. Check the toggle on the extension’s details page first.

Is Violentmonkey safer than Tampermonkey?

Violentmonkey is auditable and Tampermonkey is not: Violentmonkey is open source under an MIT-style licence with a public change history, while Tampermonkey is closed source. That is a difference in verifiability rather than a finding that either has behaved badly, and both can read and modify every page you visit.

Which userscript manager works on Safari?

Tampermonkey, through a paid App Store extension. Violentmonkey has no official Safari build.

Will my scripts and their settings transfer if I switch managers?

The scripts will. Values stored through GM_setValue do not transfer automatically, in either direction, so anything a script saved, such as an API key or a configured list, needs exporting separately.

What is the difference between a userscript manager and a browser extension?

A userscript manager is itself an extension. What it adds is the ability to run small scripts you supply, per site, without packaging and installing each one as its own extension. That is also why Chrome gates it behind a consent toggle: the manager’s whole purpose is to run code the browser never reviewed.

Do userscripts still work on pages with a strict Content Security Policy?

Generally yes. Managers run scripts in an isolated world where the page’s CSP does not apply to your code, which is why a userscript can do things the page itself is forbidden from doing. The friction appears when a script crosses back into the page’s own context through unsafeWindow, or injects elements the policy rejects.

Are userscripts safe?

The manager is not the risk; the scripts are. A userscript can read and modify every page it matches, including banking and email. Read the source before installing, narrow any @match that covers the whole web, and remember that @updateURL means the code can change after you have read it.

Sources

Every price, limit and date above was checked against these pages on the day shown. Where a figure has since moved, the vendor’s own page is the authority and this one is a snapshot.

1. 1chrome.userScripts · Chrome for DevelopersEstablishes Chrome 120+ and MV3 as the requirement, the userScripts permission, and that the toggle differs by version: Developer Mode before Chrome 138, a per-extension "Allow User Scripts" switch from 138. States that from 138 the API is undefined rather than throwing when the toggle is off.Checked 15 September 2026
2. 2Tampermonkey vs Violentmonkey: Which to Use · HatScriptsSource for the licensing difference, the Safari and Android availability, the sync provider lists, the GM_setValue caveat and the relative pace of GM. API adoption. A secondary source, used where the two vendors do not publish a directly comparable statement.Checked 15 September 2026
3. 3Violentmonkey · ViolentmonkeyProject home. Confirms open source status and the browsers with official builds.Checked 15 September 2026
4. 4Documentation · TampermonkeyReference for the GM_ and GM. API surface, the script header directives including @match and @updateURL, and the dashboard features described here.Checked 15 September 2026
5. 5GM_xmlhttpRequest limited per browser/script manager (issue 1040) · TampermonkeyCommunity reports of MV3 request handling differences, including FormData encoding and binary responses. Cited as evidence that the translation to fetch under service workers is not perfectly lossless, not as a vendor statement.Checked 15 September 2026
6. 6FireMonkey Help · FireMonkeyConfirms FireMonkey manages user scripts and user styles in one Firefox extension.Checked 15 September 2026