Ofuscador de JavaScript (Básico)

What obfuscation is — and what it isn't

Obfuscation makes source code hard for a human to read while keeping it functionally identical for the machine. It is not encryption and it is not security: anything the browser can run, a browser can also show you. This tool exists to teach how the common transformations work by letting you apply them and immediately reverse them. The warning at the top is the honest truth — obfuscated JavaScript can always be recovered, because the engine that executes it has full access to the real code. Treat this as a learning lab, not a vault.

The three levels, transformation by transformation

The tool stacks transformations as you raise the level, so each level includes everything below it:

• Low — strip comments and whitespace. Single-line (//) and block (/* */) comments are removed and runs of whitespace collapse to single spaces. This is essentially minification: smaller and less readable, but every name is intact.
• Medium — rename identifiers. On top of minifying, your variable and function names are replaced with short generated tokens like _a, _b, _c. A reserved-word list protects language keywords and built-ins (console, Math, JSON, Object, and so on) so the code keeps working.
• High — encode strings and wrap in eval. Every string literal's characters become \xNN hex or \uNNNN unicode escapes, so a readable message like "Hello" turns into "\x48\x65\x6c\x6c\x6f". The whole result is then base64-encoded and wrapped in eval(decodeURIComponent(escape(atob("...")))), hiding the structure behind a single decode-and-run call.

A worked example

Start with the factorial sample the tool loads by default:

function factorial(n) { if (n <= 1) return 1; return n * factorial(n - 1); }

At Medium, the comment vanishes, whitespace collapses, and the names change. factorial and n become tokens like _a and _b, producing something close to function _a(_b){if(_b<=1)return 1;return _b*_a(_b-1)}. The logic is untouched — call it with 10 and you still get 3,628,800 — but the intent is muddier. At High, the string in the console.log line becomes hex escapes and the entire function disappears into one long eval(atob(...)) line. The tool also reports the size change, e.g. 240 → 156 chars (-35.0%), so you can see minification shrinking the code while string-encoding later grows it back.

The deobfuscator, and why names can't come back

The second tab reverses the mechanical steps: it un-escapes \xNN and \uNNNN sequences back into characters, detects the eval(atob(...)) wrapper and decodes the base64 payload, then re-indents by adding newlines after ;, {, and }. What it cannot do is restore original names: once customerEmailAddress has become _d, the meaningful name is gone forever and no tool can guess it back. This asymmetry is the key lesson — string encoding and eval-wrapping are fully reversible, but renaming is lossy. Real-world minifiers exploit the same one-way property to shrink production bundles.

Legitimate reasons to use this

• Understanding minified libraries. Paste a chunk of a minified script into the deobfuscator to make it readable enough to study or debug.
• Learning what attackers' code looks like. Malicious scripts often hide behind eval(atob(...)); decoding the payload reveals what it actually does.
• Light deterrence. Renaming raises the effort to casually copy your client-side logic — useful against the laziest copying, nothing more.
• Teaching. Toggling levels side-by-side is a clear way to show students the difference between minification and obfuscation.

Obfuscation versus minification

It's worth separating two ideas that overlap here. Minification exists to make code smaller and faster to download — it strips comments and whitespace and shortens names, and it's a standard production build step. Obfuscation exists to make code harder to understand — string encoding and eval-wrapping add nothing to performance and actually grow the file, trading size for confusion. The Low level here is essentially minification; the High level is pure obfuscation. In real projects you almost always want minification (smaller bundles) and almost never want client-side obfuscation (it's reversible and slows the parser), which is exactly the lesson this side-by-side comparison makes visible.

Important limitations and a privacy note

The renamer uses naive pattern matching, not a real JavaScript parser, so it can occasionally rename something it shouldn't or miss an edge case — always test obfuscated output before relying on it. For genuine intellectual-property protection, client-side obfuscation is the wrong tool entirely: keep secret logic on a server you control, enforce licensing server-side, or compile to WebAssembly. On privacy, the tool runs completely in your browser — your pasted code is never uploaded — so you can safely experiment, even with code disconnected from the network.