Frequently Asked Questions
General Questions
Common questions about JavaScript obfuscation and how it works.
There are numerous reasons to protect your code: prevent anyone from simply copying your work (especially important for client-side projects like HTML5 games), make the code harder to understand and modify, and protect work that hasn't been paid for yet so you can show clients a working build without handing over the source code.
Standard obfuscation rewrites your JavaScript into harder-to-read JavaScript: names are replaced, strings are moved and encoded, control flow is restructured, but the result is still JavaScript that a debugger can step through. VM (Virtual Machine) obfuscation compiles the bodies of your functions into custom bytecode and ships an embedded interpreter that runs it, so the protected logic no longer exists as JavaScript. See VM Obfuscation for which functions are covered and how to select them.
Yes. Set vmTargetFunctionsMode to comment, then mark each function to protect with /* javascript-obfuscator:vm */. Keep these comments through any build step that runs before obfuscation. See Targeting Specific Functions.
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, whether the analysis is done by a person, a tool or an AI assistant; 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.
First rule out the runtime defenses. VM Self Defending and VM Debug Protection intentionally break under automation tools, headless browsers and debuggers, and when target does not match the real runtime, so run functional tests against a separate testing build with them turned off. If that build still breaks, narrow the problem down with vmTargetFunctionsMode: 'comment' to virtualize one function at a time. The troubleshooting guide walks through each step and lists what to include in a bug report.
The obfuscator adds code: identifiers get generated names, strings move into a string array with accessor functions (optionally encoded), and with VM obfuscation an entire virtual machine interpreter is bundled with your bytecode. Don't worry too much about size - obfuscated code compresses well with gzip or Brotli, 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. Rewriting the output can break it, especially with Self Defending or VM Self Defending, which detect changes to the code. You can run a minifier before obfuscation, as long as it keeps javascript-obfuscator comments such as /* javascript-obfuscator:vm */.
We don't keep your source code. Basic obfuscation of JavaScript runs in your browser. VM and HTML obfuscation send the source to our servers, which process it and discard it; when a request is larger than 4.4 MB, Team and Business plans upload it to temporary storage that is deleted after processing. For abuse handling and usage analysis we keep, for three months, a SHA-256 hash of each obfuscated output and a few of the settings used (such as the preset, target and VM defenses), never the code itself or any content from it. Dashboard history is stored only in your browser; manage it from History.
No. The obfuscator does not keep your original names, comments or formatting, so the output cannot be turned back into your source. That is not a security guarantee (see the question on deobfuscation above), but it does mean you must 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; test newer syntax against the obfuscator version you select. Compile TypeScript and JSX and bundle your application before obfuscating - see Runtime Compatibility. HTML files are supported through parseHtml; see Obfuscating HTML Files.
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 4 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.
Pricing & Account
Questions about plans, billing, and usage limits.
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 every month on the monthly anniversary of your subscription start, including on yearly plans. The free plan has a lifetime limit that does not reset. Plans with a daily VM limit can obfuscate with VM again the next day once that limit is reached. 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.
