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. Unlike standard obfuscation which still produces readable JavaScript, VM obfuscation completely hides your original code structure. Static analysis tools cannot understand the logic without first reverse-engineering the entire virtual machine. Learn more in our VM obfuscation guide.

Yes! We provide an option to selectively apply VM obfuscation to specific functions or methods. Simply annotate your target function with a special comment (/* javascript-obfuscator:vm */), and only that function will be processed through the VM obfuscator. This is ideal for protecting only your most sensitive algorithms while keeping the rest of your code with standard obfuscation or untouched, minimizing performance overhead.

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.

No obfuscation is 100% foolproof since JavaScript must ultimately run in the browser. However, no automated deobfuscator exists for VM-obfuscated code — each obfuscation compiles code into custom bytecode with a unique virtual machine, making universal tooling impossible. Standard obfuscation is much easier to defeat: it can often be partially reversed using automated tools and beautifiers. VM obfuscation requires fully reverse-engineering the virtual machine, decrypting and decoding its bytecode, understanding its instruction set, and tracing execution — a process that can take weeks of dedicated effort. Without VM Self Defending, powerful AI agents (e.g. Claude Opus 4.6) can trace bytecode and attempt to reconstruct original code for smaller codebases. With VM Self Defending enabled, anti-hooking defenses, cross-realm integrity verification, and bytecoded nativity checks actively block automated tracing — making even prolonged AI analysis fail to produce fully meaningful results. To further harden your code: wrap sensitive functions in an IIFE so names get fully transformed, and enable hardening options like bytecode encryption. Learn more about how VM transforms code.

VM obfuscation is a complex technology, and some edge cases may not be fully supported. If your code breaks after VM obfuscation, you can narrow down the issue by using vmTargetFunctionsMode: 'comment' to selectively obfuscate specific functions. See our troubleshooting guide for step-by-step instructions on how to identify the problematic code and report the issue.

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.

Any obfuscation will have some impact on performance. Standard obfuscation has minimal overhead. VM obfuscation has more impact: low preset ~3x slower, anti-LLM preset with Self Defending and Debug Protection ~3.5x slower. Performance heavily depends on the code — for example, recursion-heavy bytecoded code will be noticeably slower. You can fine-tune the balance by adjusting options or selectively applying VM obfuscation only to sensitive code sections. See our best practices guide for optimization tips.

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.

For files under 4.4MB, the source is processed entirely in memory and immediately returned as obfuscated output. For larger files, we temporarily upload them to secure storage and delete them immediately after obfuscation completes. As an additional safeguard, a cleanup job runs every 5 minutes to remove any files older than 5 minutes. Your code is never retained.

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.

We support ES2015 (ES6) and all modern JavaScript features including ES2022+ syntax, private class fields, async/await, optional chaining, and more. TypeScript and JSX must be compiled to JavaScript before obfuscation. With a paid plan, you can also obfuscate HTML files — add the data-javascript-obfuscator attribute to any <script>tags you want to protect, and they'll be obfuscated individually while preserving the HTML structure. Note that code in each marked script must be self-contained (no references to other scripts), and ES module scripts are skipped.

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.