JavaScript Obfuscator

Features

• Removes every comment and all redundant whitespace
• Escapes strings as hex or Unicode (non-Latin text uses \u, so bytes stay intact)
• Writes numeric literals in hexadecimal
• Renames local variables to `a`, `b`, `c` … leaving top-level names alone
• Optional: drop `console.*` calls
• Reports the size change and how many bindings were renamed
• ⚠️ Does not protect code — the page says so too, with reasons below

How to use

1. Paste your JavaScript into the left pane
2. Adjust renaming, string encoding, numbers and console handling as needed
3. Press Ctrl/⌘ + Enter or click Run
4. Copy the result with the button on the first row

FAQ

Is the code safe once it is obfuscated?

No. This is the one thing most worth being clear about. For JavaScript to run in a user’s browser, the source has to be delivered to that browser — and anything delivered to a browser can be obtained by the user. Obfuscation makes the source *harder to read*, not impossible to obtain. Those two get conflated constantly. Concretely, for what this tool does: renaming is only a change of labels — call relationships, loops and branches are exactly as they were. String escapes are decoded by the browser at runtime, so pasting the output into a console shows the originals. Stronger obfuscation (control-flow flattening, encrypted string arrays, anti-debugging) does cost a reader a few extra hours, but deobfuscators keep pace — and the price is that your production stack traces turn into `a`, `b`, `c`, which makes real incidents much harder to diagnose. The conclusion: anything that needs to stay secret must not ship to the front end. Keys, signing logic and business rules belong on the server, with the client calling an API.

Why were some variables left alone?

Each case is deliberate. Top-level declarations are never touched — they may be module exports (referenced by name from elsewhere) or globals shared with other scripts on the page, and neither is visible from the code itself. Imported names are left alone, since they refer to another module’s export. Property names are left alone (`userName` in `obj.userName`): renaming one would read a property that does not exist — and if `obj.userName` were changed while `obj["userName"]` was not, the two would disagree. Separately, if the code contains `eval`, `with` or a dynamic `import()`, renaming is abandoned for the whole file — those three can assemble variable names at runtime, and static analysis cannot follow. The results panel names which one triggered it.

Will obfuscated code still run correctly?

Yes — the semantics are unchanged. Renaming and escaping are meaning-preserving transformations; the output is behaviourally equivalent to the input. That said, correctness here is not something to take on faith. The one way renaming can go wrong is by touching something it should not have, and that failure does not throw — it silently changes a result. So the test suite is built around running each snippet before and after and requiring identical results, covering closures, destructuring (including shorthand `{x}` and defaults `{x = 1}`), per-iteration `for (let)` bindings, labelled jumps, `class` getters, optional chaining, template literals, regex and BigInt — the spots that break first. Still: run your own tests against obfuscated output before shipping. It may surface a path your tests never covered.