Encode Strings respells string literals as escaped character sequences, so the original text no longer appears literally anywhere in the output file. It is the cheapest way to stop a plain text search from finding your strings, and it is the option most often paired with Move Strings Into Array.
Example
A readable string such as "tabIndex" is rewritten as "\x74\x61\x62\x49\x6E\x64\x65\x78".
if (d === "\x74\x61\x62\x49\x6E\x64\x65\x78") {
var b = c.getAttributeNode("\x74\x61\x62\x49\x6E\x64\x65\x78");
}
The two forms are the same string as far as JavaScript is concerned. "\x74\x61\x62" and "tab" compare equal, hash the same, and serialize the same. Nothing about your program's behavior changes — only the bytes in the file.
What it buys, and what it does not
What it buys: grep, strings, browser search, and the "find in bundle" workflow all stop working on your literals. An analyst scanning a 2 MB bundle for apiKey or subscription_expired gets no hits, and has to switch from searching to reading.
What it does not buy: any resistance at all to a tool that decodes escapes. That is a one-line transformation, every JavaScript beautifier does it automatically, and a browser's DevTools console will print the decoded value if you paste the literal in. Treat this option as a defence against scanning, not against analysis.
Because of that, encoding on its own is thin. Its real value is compositional: once strings have been swept into a table by MoveStrings, encoding the table entries means the table no longer reads as a helpful index of everything your file cares about.
Configuration
On its own, respelling literals in place — this works on every plan, including Free:
{
"options": {
"EncodeStrings": true
}
}
Combined with the string table, which is the stronger arrangement. Note that MoveStrings requires a Corporate plan, so this pairing is not available on Free:
{
"options": {
"MoveStrings": true,
"EncodeStrings": true
}
}
From the open-source javascript-obfuscator package, both unicodeEscapeSequence and some values of stringArrayEncoding map to EncodeStrings. The mapping table is on the npm migration page.
To keep specific literals verbatim — protocol constants, selectors another system also declares — list them in reservedStrings. Matching literals are excluded from both MoveStrings and EncodeStrings.
Cost
Every encoded character costs four bytes (\x6E) instead of one, so an encoded file is meaningfully larger before compression. Over the wire the gap narrows sharply, because escape sequences are highly repetitive and gzip handles them well. If raw size matters — an inlined script, a size budget measured on disk — measure it rather than assuming; the numbers across 42 libraries are in how much bigger does obfuscation make your bundle.
Runtime cost is effectively zero. Escapes are resolved by the parser when the file loads, not on each read, so unlike Encrypt Strings there is no per-access work.
Stronger alternatives
- Encrypt Strings (
EncryptStrings, Enterprise) rebuilds values through generated runtime logic instead of a fixed respelling, so a beautifier alone does not recover them.
- VM protection moves selected functions to bytecode, which removes the literal from the JavaScript source form entirely.
- Neither is a place to put a secret. Anything shipped to a browser is readable by the person running the browser — see you cannot hide an API key in JavaScript before deciding a string needs this treatment at all.
Interaction with SelfCompression: when
compression is enabled the final script is packed into a compressed wrapper, so encoded literals are no longer visible in the shipped bytes regardless of this setting — the practical benefit overlaps. Enabling both is harmless, but do not expect the two to add up. Verify strict-mode behavior in your own tests when you combine compression with string transforms, rather than assuming the combination is a no-op.