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.

No obfuscation is 100% foolproof since JavaScript must ultimately run in the browser. However, there's a massive difference between protection levels. VM obfuscation offers the strongest protection: an attacker must fully reverse-engineer the custom virtual machine, understand its instruction set, trace bytecode execution, and manually reconstruct the original logic — a process that can take weeks or months of dedicated effort. Standard obfuscation is much easier to defeat: it can often be partially reversed using automated tools and beautifiers, with a skilled attacker potentially restoring readable code in hours.

No. There is no existing deobfuscator for VM-obfuscated JavaScript code, and it's unlikely one will ever be created in the upcoming years. Unlike standard obfuscation where patterns can be recognized and reversed, VM obfuscation compiles code into custom bytecode with a unique virtual machine. Each obfuscation produces different bytecode structures, making automated deobfuscation an extremely complex task. A reverse engineer would need to manually analyze the specific VM implementation, understand its instruction set, and trace through bytecode execution — a process requiring significant expertise and potentially weeks or months of work for complex code.

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 ~3.5x slower, medium ~4x, high ~4.5-5x. 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 to remove dead code and do other optimizations, though.

No. The source is processed entirely in memory and immediately returned as obfuscated output. Nothing is saved to disk or retained after processing. Your code remains yours alone.

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. We only support pure JavaScript files — HTML files containing inline JavaScript and JSX are not supported. TypeScript and JSX must be compiled to JavaScript before obfuscation.

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.

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, we only support JavaScript. TypeScript and JSX must be compiled to JavaScript before obfuscation. We support all modern JavaScript features including private class fields, ESM imports/exports, async/await, optional chaining, nullish coalescing, and other ES2020+ syntax.

No, we never store your code. For both legal and privacy reasons, your source code is processed entirely in memory and immediately returned as obfuscated output. Nothing is saved to disk or retained after processing. Your code remains yours alone.

Any obfuscation will have some impact on performance and bundle size. The exact impact depends heavily on your code size and obfuscation settings - stronger protection typically means slower execution and larger output. For VM obfuscation specifically (measured on the obfuscator itself obfuscated via VM obfuscation): low preset results in approximately 3.5x slower performance, medium preset introduces about 4x slowdown, high preset causes ~4.5-5x slowdown. You can fine-tune the balance between security and performance by adjusting individual options. Ideally, only code that truly needs protection should be obfuscated. For example, don't obfuscate third-party libraries or project dependencies - focus on protecting your proprietary business logic and sensitive algorithms.

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.

Usage is measured by the size of your input source code in bytes. Each obfuscation job has a minimum charge of 0.1 MB (102,400 bytes) to ensure fair resource allocation. For example, if you obfuscate a 50 KB file, it will count as 0.1 MB toward your quota. Files larger than 0.1 MB are charged at their actual size.

Once you reach your VM obfuscation limit, you can continue using standard (browser-based) obfuscation for free with no limits. For paid plans, your VM quota resets at the beginning of each billing cycle. The free plan has a lifetime limit that does not reset. You can upgrade your plan anytime to get more VM obfuscation quota.

Yes, you can upgrade or downgrade your plan at any time. When upgrading, you'll be charged a prorated amount for the remainder of your billing period. When downgrading, the new price applies starting from your next billing cycle.

You can cancel your subscription at any time. You'll retain access to your plan until the end of your current billing period. Please note that we do not offer refunds for partial billing periods or unused time.

We accept all major credit cards (Visa, Mastercard, American Express) and debit cards through our secure payment processor, Stripe. All transactions are encrypted and PCI-compliant.