JavaScriptVM Obfuscation

There are numerous reasons to protect your code: prevent anyone from simply copy/pasting your work (especially important for client-side projects like HTML5 games), remove comments and whitespace to make code faster to load and harder to understand, and protect work that hasn't been paid for yet so you can show clients without giving them the source code.

VM (Virtual Machine) obfuscation transforms your JavaScript code into custom bytecode that runs on an embedded interpreter. VM protection applies to eligible functions. In root mode, vmWrapTopLevelInitializers can also wrap eligible initializers for virtualization; current VM presets enable it. Review coverage warnings such as VMNoFunctionsToVirtualize, and use comment mode to select sensitive functions explicitly. Obfuscation increases the effort needed to understand and modify code; it cannot guarantee that reverse engineering is impossible. The runtime remains observable in an environment an attacker controls. Keep secrets and authoritative security decisions on the server. VM Obfuscation.

Set vmTargetFunctionsMode to comment, then mark each selected function with /* javascript-obfuscator:vm */. Preserve these comments until the obfuscation step.

No. API keys, secrets, and credentials must NEVER be stored in frontend code. Even with the highest level of obfuscation, any data in frontend JavaScript can be extracted by a determined attacker. Obfuscation makes reverse engineering harder, but it is not encryption and should not be relied upon for securing secrets. Instead, store secrets on your backend server, use environment variables on the server side, proxy API calls through your backend to hide keys, or use short-lived tokens issued by your server.

Obfuscation increases the effort needed to understand and modify code; it cannot guarantee that reverse engineering is impossible. The runtime remains observable in an environment an attacker controls. Keep secrets and authoritative security decisions on the server. How VM Transforms Code.

These defenses also act against your own agents, automation, and debuggers. They may stop execution, throw unrelated errors, or produce incorrect results. Use a separate Testing build for functional tests. Run the original code first, then run the obfuscated testing build through the same checks. Record the input, effective options, obfuscator version, and build warnings so failures can be reproduced. Troubleshooting.

The obfuscator introduces new code to protect against debugging and reverse-engineering. Strings are converted to hexadecimal, and with VM obfuscation, an entire virtual machine interpreter is bundled with your bytecode. Don't worry too much about size - the obfuscated code compresses extremely well with GZIP, which most servers enable by default.

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. Options Reference · Best Practices

No, it's not recommended and in some cases it will break the code (especially if you enable self-defending). You can run your code through a minifier before obfuscation, though.

Basic obfuscation can run locally in your browser. Cloud obfuscation processes source on the server. If the complete serialized request exceeds 4.4MB, eligible plans use temporary uploads, which are deleted after processing and covered by cleanup jobs. Dashboard history may also store source and output locally in your browser; manage it from History.

No, it's impossible to revert the obfuscated code back to your original code, so keep the original safe.

Yes. You can select "Node" as the target in the obfuscation options to optimize the output for Node.js environments.

Supported JavaScript includes ES2015+ syntax, async/await, optional chaining, and private class fields. Compile TypeScript and JSX first; test any newer syntax against the selected obfuscator version. Compile TypeScript or JSX and bundle your application before the final obfuscation step. Preserve VM selection comments until obfuscation. Do not minify, format, or otherwise rewrite self-defending output afterward. Source maps are unavailable for VM and HTML obfuscation. With parseHtml enabled, only non-empty inline scripts marked with data-javascript-obfuscator are processed. Scripts with src or type="module" are skipped, as are event attributes and javascript: URLs. Marked scripts are processed separately; do not depend on names renamed inside another marked script. Unmarked scripts can use globals that protected scripts explicitly preserve. Source maps and Evaluate output are unavailable for HTML.

The obfuscated output - including the VM interpreter and the Self Defending layer - is actively supported and tested on evergreen desktop browsers and iOS 16+ (roughly the last 3 years). Older browsers work on a best-effort basis down to a hard floor of ES2015 module support; anything below that, including Internet Explorer, is out of scope.

Check out our pricing plans for VM protection, or try the free online playground for standard obfuscation. Read the getting started guide for a complete walkthrough.