AI Didn't Kill JS Obfuscation, It Repriced It

The question making the rounds again this summer — does JavaScript obfuscation still matter when an LLM can read the output? — has a lazy answer and a useful one. The lazy answer is "obfuscation was never security, so nothing changed." The useful answer is that obfuscation was always a pricing decision, and LLMs just rewrote the price list. Some layers went to zero. Some barely moved. Knowing which is which is the whole game.

The cheap layer is gone

Identifier renaming was the first thing every obfuscator did and the first thing LLMs solved completely. humanify is the canonical example: the model never touches structure, it just proposes names, and an AST rewriter (oxc, in the current version) applies them with correct scoping. Feed it a minified bundle and you get back fetchCartTotals instead of _0x4a2b. The README quotes roughly $0.10–$1.00 per file with ~500 identifiers on OpenAI's small models; a local Ollama model does it for free, slower. That's the entire economic moat of name mangling, gone.

The structural transforms — string arrays, control-flow flattening, dead-code injection — are a more interesting story, and it's worth being precise about what the research actually shows.

JsDeObsBench, published at ACM CCS 2025, built 36,260 samples by running javascript-obfuscator over CodeNet programs with sampled combinations of seven transforms. GPT-4o produced output that executed correctly 93.4% of the time; open-weight models trailed badly (Mixtral under 30%). The two deterministic baselines, JS-deobfuscator and Synchrony, hit ~84% execution correctness but barely simplified anything. String obfuscation was the transform that hurt LLMs most.

Read the fine print, though. Those samples are competitive-programming solutions: a few dozen lines, one function, no runtime dependencies. That is the best case for a language model — the whole program fits in context, and there's no anti-debug trap or environment check to trip over. A 2 MB production bundle with a runtime-decoded string table is a different animal. Which is exactly why the tooling that works at scale doesn't look like "paste it into a chat window."

What real deobfuscation looks like now

Google's CASCADE, accepted at ICSE-SEIP 2026, is the clearest signal of where this is heading. It doesn't ask Gemini to rewrite the program. It asks Gemini to find the prelude functions — the string-array decoder, the rotation wrapper, the proxy calls that every obfuscator.io-style build generates — and then hands the actual transformation to JSIR, a compiler-style intermediate representation. The paper says this replaced "hundreds to thousands of hardcoded rules," and it's running in production at Google.

That hybrid pattern is the same shape as humanify (LLM proposes, deterministic engine disposes), and it's the same shape as the open-source ecosystem that predates LLMs entirely. webcrack will already strip obfuscator.io transforms and unpack webpack/browserify bundles with zero AI, because obfuscator.io's output is a known grammar. The LLM's contribution is the last mile: naming things, explaining intent, and finding the decoder in a build where the obfuscator randomized its shape.

So the honest accounting is: against the free, static, widely-used obfuscator, deterministic tools were already most of the way there, and LLMs closed the readability gap. If your protection strategy was npx javascript-obfuscator with controlFlowFlattening: true, it now costs an attacker an afternoon and a few dollars of API spend instead of a week. And you paid for that protection in perf — obfuscator.io's own docs put control-flow flattening at roughly 1.5× slower.

The counter-moves, and how much to trust them

Two things push the other way.

The first is per-build polymorphism plus runtime dependence. Jscrambler has leaned hard into "LLM-resilient" marketing, arguing that unique output per build defeats analysis at scale. Their own 2023 test showed GPT-4 failing outright against control-flow flattening and string concealing while happily de-minifying. That result is three model generations old, and the current pitch offers customer testimonials rather than measurements, so treat it as a claim rather than a finding. But the underlying logic holds: transforms that require executing the code to resolve (runtime-generated strings, environment-keyed decoding, self-defending wrappers) stay expensive for any static reader, silicon or carbon.

The second is adversarial obfuscation aimed at the model itself. Acoda, posted to arXiv in June 2026, uses a genetic algorithm over eight semantics-preserving transforms to make seven LLMs — GPT-4o, DeepSeek, Qwen, Llama, Gemma among them — either refuse or misread the code, with attack success up to 70% and low runtime overhead. It's clever, and it's also brittle by construction: part of the effect rides on safety-alignment quirks, and those change with every model release. I'd file it under "research direction," not "ship it."

The decision, in practice

Don't start with the obfuscator. Start with a one-line threat model: who is reading this, what do they get, and what does it cost them.

• Secrets, entitlements, billing, auth. Never in the client, obfuscated or not. This was true before LLMs; the only thing that changed is that the person who ignored it now gets caught in minutes. Move the check to the server and put a rate limit in front of it.
• Ordinary app UI. Skip it. The transform buys you nothing an attacker wants, and you eat the perf hit, the broken stack traces, and the source-map hygiene problem.
• Cloneable client-side logic — a rendering engine, a game's rules, a browser-extension's core, an algorithm that has to run locally for latency. Obfuscation still raises the cost of a faithful copy, which is the thing that matters for cloning. The catch is that against modern tooling, the free tier mostly slows down casual copying; if the asset is worth real money, you're in commercial-tool territory whether you like it or not.
• Anti-bot, fraud signals, device fingerprinting. This is where obfuscation actually earns its keep in 2026, because the adversary is automated and the script is meant to be short-lived. Polymorphic per-session builds turn "deobfuscate once" into "deobfuscate every request," and that's a cost structure LLMs don't fix.

If you do ship it: obfuscate last, after tests and lint. Test the obfuscated bundle in the browsers your users actually run, with your real perf budget. Upload source maps only to your error tracker, never to the CDN. Keep an unobfuscated build for incident response, because the first time you debug a production crash through a flattened switch state machine you will regret every setting you enabled.

Verdict

AI didn't kill obfuscation; it killed the illusion that the free, static kind was doing much. Renaming is worthless, obfuscator.io defaults are an afternoon's work, and the surviving value has migrated to runtime-dependent, polymorphic, server-coupled protections — a narrower and more expensive product than most teams need. For the majority of front-end code, the right response isn't a better obfuscator. It's less logic in the browser.