JavaScript Obfuscator

Name mangling replaces local variables and parameters with short meaningless identifiers, which removes the naming that makes code self-describing — the logic is intact but you no longer know what anything represents. String encoding rewrites literals as hex escapes, so text that would otherwise be greppable no longer appears in the file; a debugger still shows the decoded value at runtime. Dead-code injection adds branches that can never execute, padding the file so that the real logic is a smaller fraction of what you read. Each one costs bytes and clarity, and none of them changes what the program does.

They are easy to confuse because both produce unreadable output, but the intent is opposite. Minification wants the smallest file that behaves identically; unreadability is a side effect of removing everything unnecessary. Obfuscation wants unreadability and pays for it in size — dead code and hex escapes make the file deliberately larger. If your actual goal is a faster page, minify. Obfuscate only when the point is specifically to frustrate a reader, and accept that you are making the file bigger and slower to do it.

Not really, and this is the most important thing to understand before using it. Anything the browser can run, a reader can recover: they can format the output, step through it in a debugger, watch what it does at runtime, and read every value it handles. Obfuscation raises the effort required for a casual look — it will stop someone idly copying a snippet — but it does not stop anyone who is genuinely interested. Treat it as a speed bump, never as a security control.

No. This is the single most common misuse and it fails completely. A key that reaches the browser must be readable by the browser, so it is readable by whoever is using the browser — encoding it as hex escapes only means someone has to open devtools instead of the source view. Anything that must stay secret belongs on a server that your client calls; if a key has to exist in client-side code, scope it to what it is allowed to do and restrict it by referrer or origin.

Three, and they are not small. Obfuscated code is bigger, because hex escapes and injected dead code add bytes to a file that has to be parsed on the main thread. It is undebuggable, so a production stack trace becomes almost useless. And it is a well-known signal to security scanners and reviewers — obfuscated JavaScript is what malware looks like, so it can get your script flagged. Weigh those against a benefit that amounts to inconvenience for casual readers.

When the goal is deterring casual copying rather than protecting a secret, and the cost of being read is commercial rather than a security breach. A licensing check you want to make tedious to remove, a widget you distribute to customers, a puzzle or game whose answers are in the source — those are defensible. What makes them defensible is that being reverse-engineered is an annoyance, not a breach. If the answer to "what happens when someone reads this" is serious, the code should not be in the browser at all.

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.