Code Obfuscator: Safe, Real Transformations Only
Full-strength JavaScript obfuscation (variable renaming, control-flow flattening, dead-code injection) requires proper scope analysis via an AST — attempting it with regex-based text manipulation is how obfuscators silently break code. This tool sticks to transformations that are provably safe without an AST: encoding string literal contents as hex/unicode escapes, stripping comments, and compacting whitespace — all verified to produce functionally identical code.
Only string and comment segments are ever rewritten; surrounding code and template-literal expressions are passed through untouched.
Why Tokenization Comes First
Blindly find-and-replacing characters in raw source text risks corrupting code that happens to contain similar-looking patterns inside a string, template literal, or comment. This tool first splits the source into typed segments — code, string literal, template literal, line comment, block comment — and only ever rewrites the segment types you've selected, leaving everything else byte-for-byte identical.
Why String Encoding Doesn't Change Behavior
`"Hello"` and `"\x48\x65\x6c\x6c\x6f"` are different source text but evaluate to the exact same runtime string — the JavaScript engine decodes escape sequences during parsing, before your code ever runs. Encoding is applied character-by-character, skipping any already-escaped sequences to avoid double-encoding.
What Real Obfuscators Add
Tools like `javascript-obfuscator` (npm) perform proper AST transforms: renaming local variables to meaningless names, splitting control flow into a dispatcher/switch structure, and injecting dead code — all of which require understanding variable scope to avoid breaking references. This tool intentionally doesn't attempt that without an AST, since a subtly wrong rename can silently break production code.
Practical Examples
Lightly Obscuring Client-Side Strings
Making config strings less immediately greppable.
- 1.Enable 'Encode string literals'
- 2.Choose hex or unicode mode
- 3.Copy the transformed code
What Gets Transformed
- String literal contents → \xNN or \uNNNN escapes
- Line and block comments → removed
- Leading/trailing whitespace and blank lines → compacted
What's Intentionally Not Attempted
- Variable/function renaming (requires scope analysis)
- Control-flow obfuscation
- Dead-code injection
- Template literal content encoding (to avoid breaking expressions)
Frequently Asked Questions
Does this rename variables like a real obfuscator?
No — safely renaming variables requires full scope analysis (knowing which identifiers are declarations vs. references vs. property names) to avoid breaking the code, which a lightweight browser tool can't do reliably. This tool sticks to transformations that are always safe: string-literal encoding, comment removal, and whitespace compaction.
How does string encoding stay safe?
The tool tokenizes your code into code/string/comment segments first, so it only rewrites characters that are genuinely inside a string literal — code, template literal expressions, and comments are left untouched, which is why the transformed code still runs identically to the original.
What's the difference between \xNN and \uNNNN encoding?
\xNN hex escapes only cover code points 0–255 (Latin-1) and are shorter; \uNNNN unicode escapes cover the full 16-bit range and are used automatically for any character above 255 even in hex mode.
Will the obfuscated code still run correctly?
Yes — string encoding, comment removal, and whitespace changes are all semantics-preserving by construction; the JavaScript engine evaluates an escaped string literal to the exact same runtime string value as the original.
Is this meant to protect proprietary code from being read?
Not seriously — encoded strings and stripped comments make code mildly harder to skim, but variable/function names, structure, and logic remain fully readable. True protection requires server-side execution or a dedicated obfuscator with control-flow transforms, and even those are reversible with enough effort.