JavaScript Deobfuscator

Obfuscated JavaScript on a page has two very different explanations. The innocent one is commercial: a vendor scrambling a licensing check or a paid widget to deter copying, or a build tool whose output happens to be unreadable. The other is that something has been injected — skimmers, cryptominers, and redirect scripts are obfuscated as a matter of course, because unreadability delays discovery and defeats simple pattern matching. Which one you are looking at is usually obvious from the recovered strings: legitimate code contacts its vendor, injected code contacts somewhere you have never heard of.

Before deobfuscating anything, look for a sourcemap. Minified files often end with a sourceMappingURL comment, and if the map is published, browser devtools will reconstruct the original source complete with real names and comments — which is enormously better than anything deobfuscation can produce. Look in the Sources panel for an original file tree, or try appending .map to the script URL. Deobfuscation is what you do when that fails, or when the file was obfuscated deliberately and no map was ever published.

No, and it is worth being clear about why. Decoding escapes and restoring indentation recovers the two things that were mechanically transformed, which is often enough to understand a script. What cannot be recovered is information that was destroyed: original variable names, comments, and function names are gone permanently once a mangler has replaced them, because nothing in the output records what they used to be. Expect readable structure and readable strings, not the original source.

Understanding code you have to deal with but did not write. Common cases are investigating a suspicious script found on a site you maintain, working out what a third-party tag or tracking pixel is actually doing, debugging a vendor library shipped without a sourcemap, and analysing a snippet someone pasted into a page. In each case the recovered strings — URLs, event names, property keys — usually tell you the purpose faster than the logic does.

Yes. Nothing you paste is ever executed; it is parsed and transformed as text, exactly like reading it in a text editor. That is precisely why this is a safer place to inspect a suspicious script than a console or a scratch HTML file, where running it is one keystroke away. If you are investigating something you believe is genuinely malicious, still avoid visiting URLs you find in it from your normal browser.

Start with the strings, because they survive best and carry the most meaning — domains it contacts, DOM selectors it touches, storage keys it reads, names of APIs it calls. That usually establishes intent within a minute. Then look at the entry points: what runs immediately, what is bound to an event, what is on a timer. Reading the logic line by line is the slowest route and rarely necessary; the strings and the entry points answer most questions.

No. Everything runs in your browser as JavaScript — your code is never uploaded, never logged, and never sent to a server. You can verify that by watching the Network tab in devtools while you work, or by disconnecting from the internet after the page loads and confirming the tools still function. Nothing you paste is executed either; it is only ever parsed as text.