ModernCalcs

Code Deobfuscator

Decode hex/unicode string escapes, fold string concatenation, and re-indent minified JavaScript.

This reverses common surface-level obfuscation (escaped strings, split concatenation, minification) — it does not undo variable renaming, control-flow flattening, or heavy commercial obfuscators (which require full AST analysis, not text transforms).
function greet(name,greeting) {
  console.log(greeting+" "+name);
  if(name==="World") {
    return "Hello, World!"
  }
  return null
}

Code Deobfuscator: Undo the Mechanical, Not the Impossible

A lot of 'obfuscated' JavaScript encountered in the wild — bundled analytics snippets, half-hearted string-hiding — uses simple, mechanically reversible tricks: escaping string characters as hex codes, splitting strings into concatenated pieces, and stripping all whitespace. This tool reverses exactly those three things, tokenizing the source first so the transformations never touch anything outside string literals.

Formula
obfuscated source → decode \\xNN/\\uNNNN in strings → fold adjacent string concatenation → re-indent by brace depth

Each pass operates on typed segments (code vs. string vs. comment), so nothing outside a string literal is ever rewritten.

Decoding Escape Sequences Safely

`\x48\x65\x6c\x6c\x6f` and `Hello` are the same runtime string — decoding just reverses which source representation was chosen. The decoder re-escapes a character if it happens to match the string's own quote character or a backslash, so the resulting string literal stays syntactically valid rather than accidentally terminating the string early.

Folding Split String Concatenation

A common lightweight obfuscation trick splits one meaningful string into several concatenated fragments (`"Hel" + "lo"`), relying on the reader not bothering to mentally reassemble them. The folder scans for a string segment followed by a bare `+` and another string segment with the same quote character, merging them into one literal — repeating until no more adjacent fragments remain.

Re-Indenting Minified Code

Minifiers strip all non-essential whitespace to shrink file size, which incidentally also strips readability. The beautifier tracks brace and parenthesis depth character-by-character, inserting a newline and matching indent after `{`, before `}`, and after top-level `;` — while specifically not breaking inside `for(;;)` parentheses, where semicolons are structural, not statement terminators.

Practical Examples

Reading a Hex-Encoded String

Decoding \x48\x65\x6c\x6c\x6f back to Hello.

  • 1.Paste the encoded snippet
  • 2.Enable 'Decode \x / \u string escapes'
  • 3.Read the plain string in the output

Reassembling a Split String

Turning "Hel" + "lo" into "Hello".

  • 1.Enable 'Fold string concatenation'
  • 2.Adjacent same-quote string literals merge automatically

What Gets Reversed

  • \xNN and \uNNNN string escapes → actual characters
  • Adjacent string-literal concatenation → single literal
  • Minified single-line code → indented block structure

What's Out of Scope

  • Renamed variables/functions (context isn't mechanically recoverable)
  • Control-flow flattening / dispatcher obfuscation
  • Encrypted or eval-wrapped payloads
  • Dead-code injection removal

Frequently Asked Questions

What kinds of obfuscation does this actually reverse?

Three concrete, mechanical transformations: decoding \xNN/\uNNNN escape sequences inside string literals back to their actual characters, folding adjacent string-literal concatenation ("a" + "b" → "ab"), and re-indenting minified single-line code into a readable block structure.

Can it undo variable renaming or heavy commercial obfuscation?

No — reversing renamed variables would require inferring original names from usage context (not mechanically recoverable), and control-flow-flattening obfuscators (dispatcher loops, opaque predicates) need proper AST-level analysis to unwind safely. This tool only performs transformations that are always safe and mechanical.

How does it avoid corrupting the code while transforming it?

It first tokenizes the source into code/string/comment segments (the same approach used by the companion Code Obfuscator tool), so decoding and folding only ever touch string-literal segments — the surrounding code structure is never altered by those two passes.

Is the re-indented output guaranteed to run identically?

The beautifier only inserts whitespace/newlines and tracks brace/paren depth — it never changes tokens, operators, or literal values, so the resulting code is functionally identical to the input (verified against minified JavaScript samples during development).

Is my code sent anywhere?

No, all processing happens locally in your browser.