Prefix for all renamed identifiers
Same seed = same output every run
// obfuscate and protect JavaScript in the browser
Obfuscate JavaScript to protect your code. Renames variables, encodes strings, wraps with self-defending closures, and shuffles arrays — browser-based, free, no signup.
Pick a preset — Light, Medium, or Heavy — or configure individual options manually. Higher protection = more expansion and slower execution.
Paste any valid JavaScript into the Input tab. Set an optional identifier prefix and seed for reproducible output.
Click "🔒 Obfuscate". Switch to the Output tab to see the result. Copy or download as a .js file ready to deploy.
The JS Obfuscator transforms readable JavaScript into functionally equivalent code that is very difficult to understand or reverse-engineer. It combines multiple techniques — name mangling, string encoding, array shuffling, and self-defending wrappers — to create a strong deterrent. All processing happens in the browser; your code never leaves your machine.
No — obfuscation is a deterrent, not true security. Determined reverse engineers with enough time can deobfuscate any JavaScript that runs in a browser, because the browser must ultimately receive and execute readable bytecode. Obfuscation raises the cost of reverse engineering significantly, but it cannot make code truly secret the way server-side encryption can.
Yes. Every transformation preserves the code's functional behaviour — only identifiers, string representations, and code structure change, not the logic. However, obfuscation can break code that relies on function names at runtime (e.g. fn.name checks, serialisation of function bodies, or eval() with variable name references). Test thoroughly after obfuscating.
Self-defending code detects attempts to format or pretty-print the obfuscated output and responds by entering an infinite loop or throwing an error. It works by running a function that formats itself and compares the result — if the code has been reformatted, the comparison fails and execution halts. It is effective against casual tampering but not against determined analysis.
Obfuscation trades file size for obscurity. String encoding and array rotation add helper functions to decode the strings at runtime. Dead code injection adds unreachable code blocks. Each technique increases file size — heavy obfuscation can expand the original by 3–5×. This is expected and unavoidable; obfuscation is not the same as minification.
All string literals in the code are extracted into a hidden array. At runtime, a custom decoder function retrieves strings from this array by computed index rather than by their literal value. The array is then rotated (elements shifted by a calculated offset) to further obscure the mapping between indices and strings. This makes it very hard to grep for specific string values in the obfuscated code.
No. All obfuscation happens entirely in your browser using JavaScript. Your source code never leaves your machine — there is no upload, no server-side processing, and no logging of your code anywhere.
JavaScript obfuscation is the practice of transforming source code into a version that is functionally equivalent but extremely difficult for humans to read or reverse-engineer. Unlike minification — which removes unnecessary characters for file size reduction — obfuscation actively works to conceal the code's intent through a combination of name mangling, string encoding, and structural transformations.
Every variable, function, and parameter name in the source code is replaced with a meaningless identifier like _0x3a2f or a1b2c3. This removes all semantic information from identifiers — a function called validateLicenseKey becomes _0x4e2a, hiding its purpose entirely from anyone inspecting the code.
String literals — the most information-dense part of any JavaScript program — are extracted, encoded, and placed in a hidden array. References to these strings in the original code are replaced with function calls that decode the string at runtime from its encoded array position. The array is then rotated by an offset to make the index-to-string mapping non-obvious. Searching for any string value in the obfuscated code yields nothing.
Conditional branches and loops are restructured using a while loop and a switch statement with a shuffled state array. The original execution flow is replaced by a jump table where each state leads to the next via a computed index rather than direct sequential code. This makes the logic very difficult to follow even after automated deobfuscation attempts.