JS
JS Obfuscator
Obfuscate JavaScript to make it hard to read.
About JavaScript obfuscation
Obfuscation rewrites JavaScript so it still runs exactly the same, but is far harder for a human to read — renaming variables to meaningless strings, splitting and encoding string literals, and rerouting the normal flow of the code through extra indirection. Unlike minifying, the goal isn't a smaller file; it's a confusing one.
The three levels trade obfuscation strength for output size and runtime cost. Low renames identifiers and moves string literals into an array; medium adds control-flow flattening (restructuring straightforward logic into a harder-to-follow state machine) and dead-code injection; high adds RC4-encoded strings, splits string literals into chunks, and enables self-defending code that breaks if the output is reformatted or run through a beautifier. Higher levels produce noticeably larger files and slower execution, so reserve high for code that's actually worth the cost, like a licensing check, rather than an entire application.
Where you'll run into it
- Making client-side logic harder to copy or reverse-engineer
- Protecting license checks or API keys embedded in front-end code
- Shipping a bundle without revealing internal function and variable names
- Raising the cost of tampering with code that runs in an untrusted environment
Frequently asked
Is obfuscated code actually secure?
No. Obfuscation raises the effort needed to read or modify code, but anything that runs in the browser can eventually be deobfuscated by a determined person. Never rely on it to protect real secrets like private API keys.
What's the difference between obfuscating and minifying?
Minifying shrinks file size while staying easy to reverse with a beautifier. Obfuscating deliberately makes the logic confusing — renamed identifiers, encoded strings, restructured control flow — even after it's reformatted.
Will obfuscation slow down my code?
Slightly, especially at higher levels — extra indirection and string decoding add a small runtime cost. For most front-end code this is negligible; for performance-critical loops it's worth testing.
What do the low, medium, and high levels actually change?
Low renames variables and functions to short meaningless names and hides string literals in an array. Medium adds control-flow flattening — restructuring your logic's branches into a harder-to-trace state machine — plus injected dead code that does nothing but adds noise. High adds RC4-encoded strings, splits literals into chunks reassembled at runtime, and self-defending code that detects and reacts to being reformatted. Each level up costs more output size and a slower runtime in exchange for more effort to reverse.