How to Back Up Your Tampermonkey Scripts

The built-in export zip

Tampermonkey’s dashboard has a Utilities tab with an Export option that bundles your installed scripts into a single zip file. This is the quickest way to capture a snapshot of everything you currently have installed, including scripts you wrote yourself and scripts installed from sites such as the HatScripts /userscripts hub.

The export dialog lets you choose which scripts to include, so you can skip anything you consider disposable or easily reinstalled.

Cloud sync options

Beyond manual export, Tampermonkey supports automatic sync to Google Drive, Dropbox, OneDrive, a WebDAV endpoint or a local folder, configured under the Settings tab. Once enabled, changes to your script list are pushed automatically, which is useful if you install and edit scripts often.

Sync is convenient but is not a substitute for an occasional manual export, since a sync misconfiguration or an account issue can leave you without access to the same backup at the moment you need it.

What is and is not included

A standard script export includes the script source code and its metadata block. It does not automatically include values stored by the script through GM_setValue, such as saved settings, tokens or cached data, unless you specifically enable the option to include script storage in the export dialog.

Check this setting before assuming a backup is complete, particularly for scripts that store login-adjacent state or configuration you would be annoyed to lose.

Also note that Tampermonkey’s own extension-level preferences, such as your chosen editor theme, keyboard shortcuts and update check interval, live separately from the script export and are generally not carried over unless you use a full browser profile backup instead of the script-only export.

Restoring on a new machine

To restore, install Tampermonkey on the new browser or machine, open the dashboard’s Utilities tab, and use the Import option to select your zip file or point it at your configured sync location. Review the list of scripts before confirming, since an import will overwrite any script with a matching name already present.

Versioning your own scripts as files

If you write and maintain your own userscripts, keep the .user.js file itself as the source of truth in a folder you back up separately, rather than relying only on what lives inside the browser extension. Bump the @version field in the metadata block each time you make a change, so the manager’s update check and diff view stay meaningful.

Treating the file as a normal text file also means you can track changes with any version control tool of your choosing, independent of the browser extension’s own storage.

Metadata fields worth double-checking before a backup

A backup is only as useful as the metadata it preserves, since the manager relies on these fields to reinstall a script correctly.

• @name and @namespace, since a mismatch on restore can cause the manager to treat a script as new rather than as an update to an existing one
• @version, so you can confirm the restored copy matches the version you intended to keep
• @updateURL and @downloadURL, which need to still point at a reachable location if you want automatic updates to keep working after restore
• @grant and @connect, worth a quick re-read after restore in case a script was edited between backups

A routine to follow

A simple, repeatable backup habit avoids most data loss scenarios.

• Export a full zip whenever you install or remove a script, not just occasionally
• Enable cloud sync as a second, automatic layer, not the only layer
• Explicitly include script storage values in the export if any script depends on saved settings
• Keep a dated copy of each export rather than always overwriting the same file
• Test a restore on a spare profile occasionally so you know the process works before you actually need it
• Store at least one copy outside of the same account or device tied to your primary sync method

Troubleshooting a failed restore

If an import appears to succeed but scripts do not show up or do not run, check the following before assuming the backup file itself is broken.

• Confirm the zip file was not partially downloaded or corrupted, since a truncated zip can import a subset of scripts without an obvious error
• Check that each restored script shows as enabled, since imports sometimes preserve a disabled state from the original backup
• Reopen the dashboard after import, since some managers require a dashboard refresh to reflect newly imported scripts
• Verify GM_getValue calls return expected data if you also restored storage, since a storage-only restore without a matching script version can behave unexpectedly

A worked backup and restore example

Suppose you are moving from an old laptop to a new one and have twelve scripts installed, three of which you wrote yourself and store settings through GM_setValue. Open Tampermonkey’s Utilities tab, choose Export, and tick the option to include script storage rather than source code alone. Save the resulting zip somewhere outside the laptop itself, such as a separate drive or cloud folder you control directly.

On the new machine, install Tampermonkey fresh, open Utilities, choose Import, and select the zip file. Review the list shown before confirming, then open each of your three self-written scripts afterward and confirm a setting you remember, such as a saved API key or a toggle state, actually carried over correctly rather than assuming the storage import worked.

Automating backups without relying on memory

Cloud sync covers the automatic side of backups, but you can go further by keeping your own .user.js source files in a folder that is itself backed up through whatever system you already use for other documents. Because a userscript is just a plain text file, this requires no special tooling beyond copying the file whenever you make a change, and it gives you a copy that exists independently of the browser extension entirely.

Security review before restoring old backups

A backup made months ago can contain a script version that has since been updated to fix a security issue, or a script whose external API has changed in a way that makes an old @connect entry point at an address you no longer trust. Before restoring an old export wholesale, skim the @connect and @grant lines of each script rather than assuming a backup from the past is automatically still appropriate to run today.

• Check whether a newer version of the same script exists before restoring an old one, since a fresh install may already fix issues the backed up copy has
• Re-read @connect entries for domains that may no longer be relevant or trustworthy
• Confirm @grant permissions still make sense for what you remember the script actually doing

Frequently asked questions about mobile and cross-device backup

Can I restore a desktop backup into a mobile manager? Generally yes, since the zip format and .user.js files themselves are not platform specific, though the import steps differ slightly between desktop dashboards and mobile apps like the Userscripts app on iOS.

Does a backup made on Chrome restore cleanly on Firefox? Yes, as long as you use the same manager on both, since the backup format is defined by the manager rather than the browser it runs in.

Backing up scripts shared across a small team

If several people rely on the same set of internal userscripts, treat the export zip as a shared artifact rather than something that lives only on one person’s machine. Store it in a shared location that everyone already uses for other files, and agree on who is responsible for bumping @version and re-exporting after a change, so people are not silently running different versions of the same script against the same internal site.

A simple convention, such as including the date in the exported zip’s filename and keeping the last few exports rather than only the latest one, makes it easy to tell which backup to restore from if a recent change turns out to cause a problem.

Frequently asked questions

Does Violentmonkey back up the same way? Yes, the concepts are the same: a manual export to a zip or individual files, plus optional cloud sync, with script storage handled as a separate option in most versions.

Can I back up just one script instead of everything? Yes, most dashboards let you open a single script and use a per-script export, or you can simply copy the .user.js source text directly from the editor.

Will restoring a backup overwrite scripts I installed after the backup was made? Only if they share the same name and namespace as a script in the backup. Otherwise, newer scripts remain untouched alongside the restored ones.