Every byte of JavaScript you ship is readable by anyone with DevTools. Obfuscation is the honest response to that fact — not "make it secret," which is impossible, but "make reading it expensive." Here's what the transforms actually do, what they cost in size and speed, and the attacks they do nothing about.
_0x3f2a. Cheapest transform, defeats the skimmer who wanted to understand your file in two minutes."TA-PRO" now finds nothing. Encodings stack: base64 for cheap hiding, RC4 when you want every string access to cost the attacker something.config.prefix access gets routed through lookups, so property names stop being a map of your architecture.Same engine, same 191-byte test function (a license-key generator), escalating settings:
| Configuration | Output size | Inflation | Runtime cost |
|---|---|---|---|
| Compact + rename only | 1,325 B | 6.9× | none |
| + unicode escapes | 1,852 B | 9.7× | none |
| + string array (base64) | 2,454 B | 12.8× | trivial |
| + control-flow flattening | 2,922 B | 15.3× | real |
| String array (RC4) | 3,970 B | 20.8× | noticeable |
Two honest notes on those numbers. Exact bytes drift a percent between runs — generated identifiers are random. And small inputs inflate hardest because the decoder machinery is a fixed cost: on a real 200 KB bundle, the same settings land in the 2-5× range, which is what production budgets usually assume.
Obfuscation has one non-negotiable contract: the output behaves identically to the input. The test function above prints TA-PRO-STU-84; after every transform level — renaming, string arrays, flattening, dead code, RC4 — the obfuscated artifact printed exactly that, executed in a sandbox. The moment you skip that check, you ship a build where an edge case in a transform became a production bug that only manifests in the obfuscated artifact, in the browser, at the customer. Point your CI at the final artifact, not the source.
The pattern that actually works: keep the valuable logic and secrets on the server, let the client hold presentation, and use obfuscation to protect the client-side logic that's genuinely yours — licensing rules, pricing heuristics, anti-cheat checks — from casual extraction.
Transform order is where teams get burned. The safe sequence: bundle → minify → obfuscate → test → ship. Running a minifier after obfuscating breaks self-defending mode by design (it detects the reformat and throws). Tree-shaking before obfuscation is fine; anything that rewrites code after it is not. And because obfuscated stack traces are garbage, keep source maps for yourself — never in the deploy.
Paste JavaScript, pick a preset, get transformed output with size stats — the real engine, running locally.
JavaScript Obfuscator →Obfuscation is a speed bump with a measured price: roughly 7× size for renaming alone, 13-21× with string arrays and heavy encoding, real runtime cost only when you flatten hot paths. Buy it when the code is worth hiding from skimmers, never as a substitute for server-side security, and always verify the artifact still runs. The JavaScript obfuscator runs the genuine engine in your browser — paste, transform, and test before you ship.
No, and the difference matters. Encryption hides data with a key the attacker doesn't have; obfuscation transforms code the attacker's browser must be able to execute, so everything needed to run it ships with it. A skilled attacker with enough time can always recover obfuscated logic. Obfuscation raises the cost of reverse engineering from minutes to hours or days — that's the entire promise.
Identifier renaming and string-array encoding with base64 are close to free at runtime and defeat casual reading — that's the sane default. Control-flow flattening is the strongest readability transform but has a real runtime cost on hot paths, so apply it to logic-heavy functions, not render loops. Rename-globals breaks external references by design, and self-defending mode throws if the code is reformatted afterward — which also breaks your own minifier if it runs later. Obfuscate last, test the output.
No. Whatever the obfuscator does, the browser has to recover the string to use it — and so does anyone watching network traffic or instrumenting the page. An API key embedded in client-side code is public, encoded or not. The fix is architectural: keep the key server-side and proxy requests, or use short-lived tokens scoped to what the client should do.
Measured on a 191-byte test function: renaming and compaction alone grow it to 1,325 bytes (6.9x); with base64 string-array encoding, 2,454 bytes (12.8x); RC4-encoded strings, 3,970 bytes (20.8x); control-flow flattening on top of the string array lands at 2,922 bytes (15.3x). Small files inflate hardest because the transform machinery is a fixed cost — a real bundle amortizes it down to the 2-5x range.
Ordering matters. Self-defending output detects reformatting and throws, so running Terser after obfuscation kills the script — obfuscate after minifying instead. Bundlers that tree-shake or transform code can also undo or collide with obfuscation assumptions, so the safe pipeline is: bundle, minify, obfuscate, ship, then run your tests against the final artifact.
Run the output, not the source. Execute the obfuscated artifact in a sandbox and compare its behavior — in testing for this guide, a license-key function printed its expected TA-PRO-STU-84 through every transform level. For real projects, point your test suite at the obfuscated bundle in CI so a transform-induced regression fails the build instead of production.