Choosing Presets
Presets are starting configurations. Choose a preset, then review the effective options for your selected obfuscator version.
Watch
Which Obfuscator.io Preset Should I Use? VM Low vs Default vs High
For version 8.0.0 and later, VM Default is the recommended production starting point. VM Low is useful for an initial evaluation because its VM Self Defending and VM Debug Protection are off. The other VM presets enable both. On the Free plan the dashboard offers VM Low only; the other VM presets and their VM options require a paid plan.
VM (8.0.0 and later)
| optionsPreset | What changes |
|---|---|
vm-low-obfuscation | VM Low starts with fewer VM defenses and leaves stringArray and vmBytecodeArrayEncoding off. Use it to evaluate VM obfuscation, not as the base of a testing build. |
vm-default | VM Default combines VM protection with string-array protection and advanced defenses. Start here for production. |
vm-high-obfuscation | VM High adds stateful opcodes, stack encoding, and a compact dispatcher. Measure the cost on your code. |
vm-ultra-high-obfuscation | VM Ultra High keeps stateful opcodes and stack encoding but not the compact dispatcher, and adds control flow flattening and additional basic transformations. This significantly reduces runtime performance. |
In version 8.0.0 and later, vm-anti-llm (VM Anti-LLM) and vm-medium-obfuscation (VM Medium) give the same options as vm-default and are no longer separate choices in the dashboard. Older versions may expose them separately.
Basic Obfuscation
| optionsPreset | selfDefending | debugProtection | disableConsoleOutput |
|---|---|---|---|
default | false | false | false |
low-obfuscation | true | false | true |
medium-obfuscation | true | false | true |
high-obfuscation | true | true | true |
Heavier presets can increase output size and execution time. Measure your own startup time, hot paths, and compressed bundle size instead of relying on fixed slowdown multipliers. To protect selected functions, see Targeting Specific Functions.
For an API build, get a built-in preset's options for your obfuscator version from the presets endpoint and send them as options (see API Reference).
Custom presets
Built-in presets are starting points. Whenever you adjust anything on top of one, save the result instead of rebuilding it next time: select New Preset in the presets library at the top of the options panel. The preset stores every option as it is set right now, under a name of your choice and an optional description; it does not store the obfuscator version, so the version selected when you build applies. Your presets are listed under Custom. Custom presets are available on Pro plans and above, up to 20 per account.
Click a preset's card to apply it to the options panel. Once you change an option, the applied preset is marked Edited: Revert changes puts its options back, and on your own presets Update preset saves the changes into it. Before another preset overrides unsaved changes, you are asked to confirm. Edit, duplicate and delete are in the preset's menu. A common setup is one production preset and a testing variant of it that adds the overrides from Testing and CI, so both builds run the same transforms.
Two more fields in the save dialog take a preset beyond your own dashboard:
- Share with my team publishes it to your team, where it can also become the team default. Only a team owner sees the switch. See Shared Presets.
- API alias lets a build use the preset by name: in the
javascript-obfuscatorpackage (5.8.0+),optionsPresetset to the alias fetches the preset's options at build time, so the configuration lives in the dashboard and a change there reaches the next build without a commit. A direct API request fetches the options from the presets endpoint in a separate request (see API Reference). See Using the NPM Package.