Threat modeling
Yes — in principle. We’d rather tell you that plainly than sell you a myth. Obfuscation is not encryption. The code has to run in the visitor’s browser, which means the machine has everything it needs to execute it, which means a determined human with enough time has everything they need to understand it. Any vendor who tells you their output is “irreversible” or “impossible to crack” is overselling. But “is it reversible?” is the wrong question. The right one is: how expensive is reversing it, and is that more than the reward?
Obfuscation is economics, not cryptography
Encryption gives you a mathematical guarantee: without the key, the data is inaccessible, full stop. Obfuscation gives you no such guarantee, because it can’t — the “key” (the ability to run the code) ships with the code. What obfuscation does instead is change the cost curve. It turns “copy this in ten seconds” into “spend a week reconstructing intent, and start over next release.” That is a real and useful defense, but it is a defense of degree, not of kind. You are not making theft impossible; you are making it not worth it.
Which means the only sensible target is your threat model. Stopping a competitor from casually lifting a widget is a low bar. Stopping a funded team from extracting a proprietary algorithm is a high one. The same tool, dialed to different strengths, addresses both — and pretending one setting fits all is how people end up disappointed.
The reversal-cost spectrum
Not all “obfuscation” sits at the same point on the curve. Roughly, from trivially reversible to genuinely expensive:
- Minification — not protection at all. It shortens names to save bytes; a formatter undoes it in one click. (See minification vs obfuscation.)
- Basic identifier renaming — raises the annoyance, but structure and strings survive, and automated deobfuscators handle it well.
- String encryption + control-flow flattening + dead code — now static analysis struggles: the strings aren’t there to read, and the control flow no longer matches the source shape. Off-the-shelf deobfuscators degrade sharply here.
- Per-build polymorphic decoders + VM bytecode — the top of the curve. Marked functions compile to custom bytecode running on an inlined interpreter, and every build produces different opcodes and a different decoder, so there is no single static target and no reusable script. (See Maximum mode and every transform side by side.)
What about automated deobfuscators and AI?
They are the honest reason this question matters more than it used to. Public tools like de4js and generic AST-based deobfuscators reverse naive obfuscation quickly, and large language models can now undo simple transforms and re-name variables into something readable. This genuinely raised the floor: basic obfuscation buys less than it did a few years ago.
It did not make strong protection pointless — it moved the bar. String encryption defeats pattern-matching that relies on reading literals; control-flow flattening removes the source-shaped structure a model leans on; and per-build VM bytecode denies both tools and models the one thing they need most, a stable target to learn. We’ve written about exactly this — can ChatGPT, Claude, or Copilot reverse-engineer obfuscated JavaScript and the LLM-deobfuscator question — and the answer is nuanced, not triumphant. The right response to better attackers is not a bigger claim; it is measurable resistance.
Measure resistance instead of claiming irreversibility
Because “irreversible” is never true, the useful thing is evidence of how much cost you actually added — something you can put in front of a reviewer instead of a marketing adjective. That is the point of our AI-resistance evidence reporting: it summarizes which strong transforms a build applied, whether VM protection ran, and the review boundaries, so a release owner can reason about the protection concretely rather than take a vendor’s word. Honesty here is a feature, not a weakness — it is what lets you match protection to threat instead of hoping.
So what should you actually do?
Decide what you’re defending against, then dial the protection to it rather than reaching for “maximum” reflexively or dismissing obfuscation because it isn’t cryptography. Anti-casual-copying needs far less than anti-IP-theft. The threat-model picker maps common goals to protection levels, and you can watch each transform’s effect in the side-by-side view. Reversible in principle, yes — but priced out of reach for the attacker you actually have is a goal you can meet.