🔒 JavaScript Obfuscator

🛡️
⚙️
📝
🔒
📊
Original Size: {{ statistics.originalSize }} bytes
Original Lines: {{ statistics.originalLines }}
Variables Renamed: {{ statistics.variablesRenamed }}
Obfuscated Size: {{ statistics.obfuscatedSize }} bytes
Obfuscated Lines: {{ statistics.obfuscatedLines }}
Strings Encoded: {{ statistics.stringsEncoded }}
Protection Level: {{ getProtectionLevelText() }} • Readability: {{ getReadabilityText() }}
⚠️

Important: Obfuscation is not encryption and should not be your only security measure.

  • Never rely solely on obfuscation to protect sensitive data
  • Always validate user input on the server side
  • Use HTTPS for all communications
  • Consider obfuscation as one layer in a multi-layered security approach
⚠️ {{ error }}

ℹ️ About JavaScript Obfuscator

JavaScript Obfuscator rewrites readable JavaScript into equivalent code that is harder to scan, copy, or casually reverse engineer. It preserves the behavior expected by the ECMAScript language specification while applying practical transformations such as identifier mangling, string encoding, whitespace compaction, and optional control-flow rewriting.

Use it when you need to ship browser-side code but want to raise the effort required to understand implementation details. Typical jobs include:

  • Preparing a production snippet, widget, or bookmarklet before publishing it on a public page.
  • Making proprietary calculations or license checks less obvious to casual inspection.
  • Producing compact output by shortening local names and removing unnecessary spacing.
  • Creating harder-to-read challenge code for training labs, CTF tasks, or demos.

Example: readable code such as function greet(name) { return "Hello " + name; } may become a compact form with short identifiers and encoded strings, for example function a(b){return atob("SGVsbG8g")+b}. String encoding uses the browser's WHATWG HTML atob() API, so the output remains executable JavaScript rather than encrypted data.

The strength presets control how aggressive the rewrite should be:

  • Light: basic renaming and compaction for small scripts where runtime readability matters less than size.
  • Medium: balanced obfuscation for normal production snippets and shared examples.
  • Heavy: control-flow flattening and dead-code injection for maximum confusion, with a larger output and more compatibility risk.

Limitations: obfuscation is not encryption, access control, or a safe place to hide API keys. Anyone who receives JavaScript in a browser can inspect, run, patch, and deobfuscate it. Follow OWASP guidance for AJAX/client-side security: keep secrets and authorization decisions on the server, validate requests server-side, and treat obfuscation as a deterrent rather than a security boundary.

Test the obfuscated output in the target browsers before deployment. Regex-heavy code, reflection, dynamic property names, source maps, and build-tool assumptions can break when identifiers are renamed or statements are compacted.

API Usage Example:

POST /api/tools/webdev/js-obfuscator
Content-Type: application/json

{
    "code": "function greet(name) {\n  const message = \"Hello friend\";\n  return message + name;\n}",
    "strength": "medium",
    "options": {
        "mangleNames": true,
        "encodeStrings": true,
        "controlFlowFlattening": false,
        "deadCodeInjection": false,
        "compactCode": true
    }
}
Ready