b2KIT

Code Obfuscator

Obfuscate JavaScript code to make it harder to reverse-engineer with variable renaming and control flow transformations.

Tested tool guide Tested browser tools Checked August 16, 2026

What Code Obfuscator does and how it behaves

Paste in JavaScript and receive a rewritten version that is deliberately hard to read: meaningful variable names become short or random labels, if/else chains and loops are reshaped into dispatch structures, and string literals may be pulled into an encoded pool that the code fetches at runtime. The output is meant to run with the same observable behavior while removing the structure a human reader would lean on. The thing users most often get wrong is treating the result as protection: obfuscation is deterrence against casual reading, not security, and the underlying logic still ships to every browser that executes it.

How the result is produced

1

Variable renaming

Identifiers that are local to a function or block are replaced with short or meaningless names, so a name like `invoiceTotal` comes back as something like `a` or `_x2`. Because renaming touches only scoped identifiers, behavior does not change, but every hint of author intent in the naming is gone. Names other code depends on, such as globals and properties read by other scripts, are typically left intact.

2

Control flow reshaping

Conditionals and loops are rewritten so the code no longer reads in the order it executes: conditions can be inverted, blocks moved, and nested branches flattened into a loop that dispatches between states. A reader following the output line by line loses the high-level shape of the original program. The trade-off is real: transformed code is larger and slower, and the cost grows with how much structure is flattened.

Good uses

  • Shipping browser-side logic - a licensing check or a client-side request signer - when you want to discourage a competitor from simply reading the page source and copying the approach.
  • Releasing a public script, such as a userscript or an embeddable widget, where you want casual copy-paste reuse of your code to be noticeably less appealing.
  • Auditing your own exposure: obfuscate a copy of a sensitive snippet and time how long it takes you to understand the output - that is roughly the effort a determined reader will invest.

Limits and checks

  • Not a security boundary: the browser must execute the output, so every algorithm, string, and key in your input is still present in the obfuscated code. A patient analyst with a debugger will recover the logic. Anything that must stay secret belongs on the server, not in client-side code, obfuscated or not.
  • Size and speed: transformed code is larger and runs slower, and the cost compounds on big scripts. Renaming is nearly free; control-flow flattening and string encoding are not. Measure the obfuscated build before shipping rather than assuming the default is acceptable.
  • Breakage and debugging: code that reads its own source with Function.prototype.toString, uses eval, or is called by another script that references a renamed identifier can fail after obfuscation. Stack traces and error messages from the transformed build are hard to read, so keep the original source under version control and test the shipped output.

Common questions

Is the obfuscated code impossible to reverse-engineer?

No. Every technique here - renaming, control-flow reshaping, string encoding - can be undone, and deobfuscation tooling exists. The tool runs in your browser and nothing is uploaded, but the output you ship is still read by anyone who loads the page. A determined analyst will recover the logic; obfuscation buys time, not secrecy. Anything that must stay secret belongs on a server you control.

Will the obfuscated output run exactly like my original code?

It is designed to: renaming and control-flow transformations are behavior-preserving by construction. Still, verify before shipping - run your test suite against the obfuscated build, not just the source. The output is bigger and slower, and debugging it later is painful, so keep the original under version control and record the settings used for each build.

References and verification

The behavioral notes were checked against the browser implementation. Standards and primary references below define the relevant format, formula, or platform behavior.

Related Tools