JavaScript Obfuscator

Compact Code	Removes line breaks from the output obfuscated code.
Self Defending	This option makes the output code resilient against formating and variable renaming. If one tries to use a JavaScript beautifier on the obfuscated code, the code won't work anymore, making it harder to understand and modify it. requires the Compact Code setting.
Control Flow Flattening	This option greatly affects the performance up to 1.5x slower runtime speed. Enables code control flow flattening. Control flow flattening is a structure transformation of the source code that hinders program comprehension. See the docs on JavaScript's obfuscator GH page for an example of how the transformation works. Control Flow Flattening Threshold You can use this setting to adjust the probability (from 0 to 1) that a controlFlowFlattening transformation will be applied to a node. In larger codebases it's advised to lower this value, because larger amounts of control flow transformations can increase the size of your code and slow it down.
Seed	By default (seed = 0), each time you obfuscate your code you'll get a new result (i.e: different variable names, different variables inserted into the stringArray, etc). If you want repeatable results, set the seed to a specific integer.
String Array	Removes string literals and place them in a special array. For instance the string "Hello World" in var m = "Hello World"; will be replaced to a call to a function that will retrieve its value at runtime, e.g: var m = _0xb0c3('0x1'); See the options below on how to configure this feature be more or less resilient. Rotate String Array Shift the stringArray array by a fixed and random (generated at the code obfuscation) places. This makes it harder to match the order of the removed strings to their original place. This option is recommended if your original source code isn't small, as the helper function can attract attention. Encode String Literals This option can slightly slow down your script. Encode all string literals of the stringArray using either Base64 or RC4 and inserts a special function that it's used to decode it back at runtime. Beware that the RC4 option is about 30-35% slower than the Base64 option, but it's more difficult to retrieve the strings back. String Array Threshold You can use this setting to adjust the probability (from 0 to 1) that a string literal will be inserted into the stringArray. This setting is useful in large codebases as repeatdely calls to the stringArray function can slow down your code.
Disable Console Output	Disables the use of console.log, console.info, console.error and console.warn by replacing them with empty functions. This makes the use of the debugger harder.
Debug Protection	Can freeze your browser if you open the Developer Tools. This option makes it almost impossible to use the Console tab of the Developer Tools (both on Google Chrome and Mozilla Firefox). Debug Protection Interval If checked, an interval is used to force the debug mode on the Console tab, making it harder to use other features of the Developer Tools. How does it works? A special code that calls debugger; repeatedly is inserted throughout the obfuscated source code.
Domain Lock	Locks the obfuscated source code so it only runs on specific domains and/or sub-domains. This makes really hard for someone just copy and paste your source code and run elsewhere. Multiple domains and sub-domains It's possible to lock your code to more than one domain or sub-domain. For instance, to lock it so the code only runs on www.example.com add www.example.com, to make it work on any sub-domain from example.com, use .example.com.
Reserved Names	Disables the obfuscation of variables names, function names and function parameters that match the Regular Expression used. For instance, if you add ^someName, the obfuscator will ensure that all variables, function names and function arguments that starts with someName will not get mangled.
Source Map	Be sure not to upload the obfuscated source code with the inline source map embedded on it, as it contains your original source code. Source maps can be useful to help you debug your obfuscated Java Script source code. If you want or need to debug in production, you can upload the separate source map file to a secret location and then point your browser there. Read more about source maps on the Google Chrome Developer Tools website. Inline Source Map This embeds the source map of your source in the result of the obfuscated code. Useful if you just want to debug locally on your machine. Separate Source Map This generates a separate file with the source map. Useful to debug code in production, as this enables you to upload the source map to a secret location on your server and then point your browser to use it. Use the Source Map Base URL and Source Map File Name to customize the sourceMappingURL property that will get appended to the end of your obfuscated code. For instance, if you set the Base URL to "http://localhost:9000" and File Name to "example", you'll get: //# sourceMappingURL=http://localhost:9000/example.js.map. appended to the end of your obfuscated code.

Why would I want to obfuscate my JavaScript code?

There're a numerous reasons why it's a good idea to protect your code, such as:

• Prevent anyone from simply copy/pasting your work. This is specially important on 100% client side projects, such as HTML5 games;
• Removal of comments and whitespace that aren't needed. Making it faster to load and harder to understand;
• Protection of work that hasn't been paid yet. You can show your work to the client knowing that they won't have the source code until the invoice has been paid.

After obfuscated, can I call a function or use a variable name which was defined within the obfuscated file from outside, for example, HTML page or the other files?

NO. Keep in mind that all the data have been obfuscated, so its almost impossible to read from outside. I suggest you put all your code into a file then import it into your HTML page. Whenever you update your code, do it in your original file then re-obfuscate into a new file again.

Is this obfuscator absolutely foolproof?

No, while it's impossible to recover the exact original source code, someone with the time, knowledge and patience can reverse-engineer it.

Since the JavaScript runs on the browser, the browser's JavaScript engine must be able to read and interpret it, so there's no way to prevent that. And any tool that promises that is not being honest.

Why my obfuscated code is larger than my original source?

Because the obfuscator introduces new pieces of code that are meant to protect and defend against debugging and reverse-engineering. Also strings are converted to \xAB hexadecimal code to make things a little bit harder to understand. You don't have to worry too much about code size because since there're a lot of repetition, the obfuscated code will be compressed extremely well by your webserver (if you have GZIP compression enabled on your server, which most do nowadays).

Can I run a minifier such as UglifyJS or Google Closure Compiler on the obfuscated output?

No, it's not recommended and in some cases it'll break the code (such as if you enable self-defending). You can run your code through a minifier before to make sure that it removes dead code and do other optimizations, though.

Do you store my source code?

No. The source is processed by our application server, then to the obfuscator and back to the browser, so it only stays on our server memory for a brief period of time (usually milliseconds).

Can I recover the original source code from the obfuscated one?

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

Does this tool works with Node.js source code?

Yes.

I want to run the obfuscator on my own server/machine. Is it possible?

Sure. This tool uses a free and open source (BSD-2-Clause licensed) obfuscator written in TypeScript. You can go to it's GitHub page and read more there.