Hex escape decoding (\xNN)
Every \xNN escape sequence is decoded to its character equivalent, both inside string literals and inside identifiers where JavaScript syntax allows.
JavaScript DeObfuscator decodes \xNN, \uNNNN, and \u{NNNN} escape sequences in your JS — both inside string literals and inside identifier characters — then reformats the result so you can actually read what the code does.
JavaScript DeObfuscator is a free, browser-based tool that takes obfuscated JavaScript and produces a readable, properly formatted equivalent. It decodes every common escape sequence used by simple obfuscators — \xNN hex escapes, \uNNNN unicode escapes, and \u{NNNN} extended unicode escapes — and then runs the result through the same beautifier we publish as a standalone tool.
JavaScript DeObfuscator is most useful when you encounter a script that looks unreadable but you suspect was produced by a casual obfuscation pass rather than a heavy production minifier with control-flow flattening. The most common case is encoded string literals: a function that calls `fetch("\x68\x74\x74\x70\x73://example.com")` becomes readable as `fetch("https://example.com")` after one pass through the tool.
Typical users are security engineers reviewing third-party tags, developers reverse-engineering a script they wrote some time ago without source maps, and educators showing the symmetry between obfuscation and deobfuscation as cryptographic friction rather than security. Because the tool runs entirely on your device, the scripts you decode never leave the browser.
Every \xNN escape sequence is decoded to its character equivalent, both inside string literals and inside identifiers where JavaScript syntax allows.
Standard \uNNNN escapes are decoded to their corresponding characters. The tool also handles the extended \u{NNNN} syntax introduced in ES6 for code points beyond the BMP.
When variable or function names are encoded as \uNNNN sequences (a common JavaScript-syntax trick), the decoder normalises them back to readable identifiers.
After decoding, the tool runs the result through the same beautifier we publish as a standalone tool. The output is properly indented and easy to scan.
Characters that already require escaping (like quotes inside the same-quote string) are re-escaped after decoding, so the output remains valid JavaScript.
All decoding happens in your browser. Scripts you investigate are never uploaded, which matters when reviewing third-party or potentially malicious code.
JavaScript syntax allows characters inside string literals to be expressed in several forms: a literal character, a hex escape (\xNN), a 4-digit unicode escape (\uNNNN), or an extended unicode escape (\u{NNNN}). All four forms are equivalent at parse time, which means a string like "hello" can be written as "\x68\x65\x6c\x6c\x6f" without changing its value. Simple obfuscators take advantage of this by rewriting every printable character in every string as an escape sequence.
Identifiers receive the same treatment. JavaScript allows a variable name to be written with unicode escapes — `foo` and `\u0066\u006f\u006f` reference the same variable. Naive obfuscators rewrite identifier characters this way so that variable and function names no longer look like words to a casual reader.
JavaScript DeObfuscator reverses both transformations. It walks the source token by token, converts escape sequences back to their character equivalents inside string literals, normalises unicode-escaped identifiers, and then runs the cleaned output through the beautifier. The result is a properly formatted, readable version of the original code — useful for security review, audit, or simply understanding code without source maps.
Input
fetch("\x68\x74\x74\x70\x73://example.com")Output
fetch("https://example.com")Some aggressive obfuscators add control-flow tricks that this tool will not reverse. After decoding, paste the result into a parser (or your editor) to confirm it still parses cleanly.
For maximum readability, run DeObfuscator first, then Beautifier, then optionally Minifier on the readable result if you need to ship it.
If you are decoding code suspected to be malicious, run the analysis in a sandbox VM or isolated browser profile. Decoded strings can include URLs and command-and-control endpoints that you do not want to visit accidentally.
When auditing a third-party tag, save both the obfuscated and decoded forms. The decoded form is easier to share with reviewers; the obfuscated form is the artifact you should reference in the bug or finding.
Some obfuscators also encode property accesses through string lookups (obj["\x66\x6f\x6f"]). DeObfuscator decodes the strings; you still have to recognise the pattern to fully restore intent. Treat the tool as a productivity boost, not a complete reverse-engineering solution.
Some sequences are inside template literals or comments that the decoder preserves verbatim. Copy the relevant substring into a fresh run for further decoding.
It is likely obfuscated with control-flow flattening or string-array lookups, not just escapes. Manual reverse engineering is required from this point.
Marketing tags often encode their network endpoints. Decoding makes the URLs visible so you can decide whether to allow the script and whether it complies with your privacy policy.
Without a source map or the original file, an obfuscated bundle is unreadable. The tool gives you a first pass at recovering structure before manual reverse engineering.
Bookmarklets that look like noise can be inspected after decoding. The decoded form often reveals whether the script does what it claims or something else.
Obfuscation is a common entry-level CTF mechanic. The tool reverses the obvious layer so the underlying puzzle becomes accessible.
Teaching obfuscation alongside deobfuscation makes clear how reversible the technique is and why it should not be used as a security control.
It decodes the most common escape-based obfuscation: \xNN, \uNNNN, and \u{NNNN} sequences. It does not reverse control-flow flattening, dead-code injection, runtime self-defending, or string-array packing produced by aggressive obfuscators like javascript-obfuscator with full features turned on.
Yes. The decoder only replaces escape sequences with their character equivalents in places where JavaScript syntax allows it (string literal contents, identifier characters). The output is still parseable as JavaScript.
No. All decoding happens in your browser. The scripts you investigate — including potentially malicious code — never leave the device during analysis.
The beautifier only reformats whitespace; it does not decode escape sequences. DeObfuscator decodes the escapes first and then reformats. For unencoded but minified code, the standalone Beautifier is the right tool; for escape-encoded code, this one is.
Decoding code is generally legal for personal review, security analysis, and academic study. Redistributing the decoded result may be restricted by the licence of the source. When in doubt, consult a lawyer.
Some obfuscators do more than encode strings — they replace identifier names with random short letters, introduce dead code, or use string-array lookups. This tool handles the encoding layer; deeper obfuscation requires dedicated reverse-engineering work.
Yes. Turn off "Reformat with beautifier after decoding" if you only want the decoded characters without the surrounding indentation changes. This is useful when you need to keep the line structure for audit purposes.
Pasting code into the tool is safe — it never executes the script. Avoid actually running the decoded result on your real machine; visit any extracted URLs only from a sandboxed environment.
JavaScript DeObfuscator turns escape-encoded code into readable JavaScript in one click — useful for security review, audit, and recovering scripts you lost the original source for.