JSON presets let you save and reuse the online obfuscator settings that usually matter during review: Standard options, premium preview features, and the Variable Exclusion List.
When to use presets
Use presets when you want repeatable settings across browser sessions, team reviews, support requests, or quick comparisons between Standard mode and premium feature previews.
- Open the online obfuscator.
- Choose Standard, Balanced Preview, Maximum Preview, or a custom feature set.
- Adjust Standard options such as string encoding, string movement, and name replacement.
- Add any Variable Exclusion List patterns that preserve public names.
- Select Export JSON Preset to save the profile.
What the preset stores
The exported preset is a small JSON file designed for the online tool. It stores configuration only; it does not include source code or obfuscated output.
{
"format": "javascript-obfuscator-web-preset",
"version": 1,
"preset": "standard",
"standardOptions": {
"keepLinefeeds": false,
"keepIndentations": false,
"encodeStrings": true,
"moveStrings": true,
"replaceNames": true
},
"advancedFeatures": [],
"variableExclusionList": "^_get_\n^_set_\n^_mtd_"
}
Importing a preset
Use Import JSON Preset in the online obfuscator to load a saved profile. The page validates the preset format and version before applying it.
If imported features do not match a built-in preset, the tool treats the result as a custom profile. That is expected and useful when you want a team-specific setting set.
Using a preset in npm builds
The npm CLI can import the same exported JSON file and map it to the HTTP API payload. This keeps browser review settings aligned with release builds.
npx jso-protector --config jso.config.json --web-preset javascript-obfuscator-preset.json --dry-run --json
In shared config, use "webPreset": "javascript-obfuscator-preset.json". Standard options, selected premium preview features, and the Variable Exclusion List are applied before any explicit options overrides.
How this differs from desktop projects
JSON presets are lightweight browser profiles for the online tool. Desktop projects are still the better visual workflow for large codebases. WinUI Local Standard processes basic ES5 .js offline; paid Local Advanced keeps modern .js/.jsx and mixed HTML/server-script source with supported advanced transforms on-device after an online entitlement check. Automation workflows use the hosted service.
Online JSON preset
Best for quick review, browser testing, and sharing option choices. |
Desktop project
Best for project batches, embedded files, local workflows, and generated command-line release steps. |
What a preset deliberately leaves out
A preset is a settings profile, not a build definition, and the omissions are intentional:
- No source code and no output. Presets are safe to attach to a support ticket or commit to a shared repository.
- No credentials. An API key or account identifier never appears in a preset, so sharing one grants nothing.
- No input or output paths. Those belong to the config file that drives a build, because they differ per machine and per pipeline.
- No seed. Reproducibility is a release decision rather than a review setting — see reproducible builds.
The practical consequence is that a preset answers “which protections did you have switched on?” and nothing else. That is exactly the question worth answering during a review, and exactly the one that is otherwise reconstructed from memory.
Version and format handling
Every preset carries a format and a version, and the importer checks both before applying anything. A file that is not a javascript-obfuscator-web-preset, or that declares a version the page does not understand, is rejected rather than partially applied — a half-applied profile is worse than none, because it looks like it worked.
If a preset lists a feature that no longer maps to a built-in profile, the tool loads it as a custom profile rather than snapping it to the nearest preset. That is deliberate: an imported profile should reproduce what the author had, not what the tool would have recommended.
A workflow that uses presets well
- Find a working option set in the browser against a representative sample of your code.
- Export the preset and commit it next to your build config, so the choices are reviewable in a pull request rather than living in someone’s browser.
- Reference it from your CI config with
webPreset so review settings and release settings cannot drift apart.
- Layer explicit
options on top for anything release-specific — locks, seeds, runtime defense — since explicit values always win over preset values.
The ordering matters: preset first, explicit overrides second. That way the preset stays the readable summary of intent and the overrides stay a short, auditable list of exceptions. For the full option vocabulary those overrides can use, see npm presets and options.
Tip: if your preset uses premium preview features, keep the online sample below 2KB. Use Standard mode for larger online files, or the desktop workflow for larger protected releases.
Frequently asked questions
What exactly does a JSON config preset store?
Settings only. A preset holds the Standard options such as string encoding, string movement and name replacement, any premium preview features you selected, and your Variable Exclusion List patterns. It carries no source code and no protected output, so it is safe to attach to a support ticket. It carries no credentials, so sharing one grants nothing. And it carries no input or output paths, because those differ per machine and belong to the build config rather than to a settings profile.
Why does a preset deliberately leave out the seed?
Because reproducibility is a release decision and a preset is a review artifact. The preset answers one question, which is which protections you had switched on when you looked at the output. A seed answers a different one, which is whether a given release can be rebuilt byte for byte later. Keeping them separate means a preset can be shared freely and reviewed in a pull request, while the seed lives with the build configuration that produces the artifact you ship.
Can the same preset drive both the browser tool and a release build?
Yes, and that is the main reason to export one. The command line tool imports the same exported JSON file and maps it onto the API payload, either with the web preset flag on the command line or with a webPreset entry in your shared config. Standard options, the selected premium preview features and the Variable Exclusion List are applied first, and any explicit options you set are applied on top. That ordering is what keeps browser review settings and release settings from drifting apart.
What happens if I import a preset the tool does not recognise?
It is rejected rather than partially applied, which is the safer failure. Every preset carries a format identifier and a version, and the importer checks both before it changes anything, because a half-applied profile looks like it worked and is worse than none at all. There is a separate and gentler case: if a preset lists a feature set that no longer matches a built-in profile, it loads as a custom profile instead of snapping to the nearest preset, so an imported profile reproduces what its author had rather than what the tool would recommend.
When should I use a desktop project instead of a preset?
When the work is a build rather than a review. Presets are lightweight browser profiles aimed at trying settings, sharing choices and comparing modes. Desktop projects are the better fit for project batches, embedded files, local workflows and generated command line release steps. There is also a processing distinction worth knowing: the Windows local paths keep your source on the device, while automation workflows use the hosted service.
What is the workflow that gets the most out of presets?
Four steps. Find a working option set in the browser against a sample that represents your real code. Export the preset and commit it next to your build config, so the choices are reviewable in a pull request rather than living in somebody's browser. Reference it from CI so review and release settings cannot separate. Then layer explicit options on top for anything release-specific such as locks, seeds and runtime defence, since explicit values always win. The preset stays the readable summary of intent and the overrides stay a short auditable list of exceptions.
