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.
Frequently asked questions
What does Encode Strings actually do?
It respells string literals as escaped character sequences, so the original text no longer appears literally anywhere in the output file. A readable literal becomes a run of hexadecimal escapes. As far as JavaScript is concerned the two forms are the same string: they compare equal, hash the same and serialise the same, so nothing about your program's behaviour changes. Only the bytes in the file are different.
What does it buy me in practice?
It stops text search from finding your literals. Searching a large bundle for a token like an API parameter name or a feature flag returns nothing, so an analyst has to switch from searching to reading, which is a much slower activity. That is a real and useful change in the cost of casual inspection, and it is why the option is cheap enough to leave on.
What does it not buy me?
Any resistance to somebody who runs the code or reads it with a tool. The strings are recovered by evaluating them, and every browser will happily print the decoded value. A debugger shows the real text at the point of use, and an automated pass over the file can decode every escape without understanding anything about your program. Treat it as a measure against searching rather than against analysis.
Should I use it together with the string table?
Yes, and that is the pairing it is designed for. Moving strings into a table changes where the literal lives, and encoding changes how it is spelled; together the literal is neither adjacent to the code that uses it nor findable by searching for its text. Each option addresses a different half of the same exposure, and most presets that use one use both.
Does it cost anything at run time or in size?
Size grows, because an escape sequence takes several characters where the original took one, and the effect is larger for text that is mostly plain characters. Run-time cost is negligible: the escapes are resolved when the source is parsed rather than on every use, so there is no repeated decoding. If size matters to you, measure it on your own bundle after compression, since compressed size is affected far less than raw size.
What should I use instead if I need something stronger?
String encryption, which is a different mechanism rather than a stronger spelling. Encoding is reversible by reading; encryption requires the runtime to decrypt through a helper, which raises the cost of static extraction considerably. It also costs more at run time and sits at a higher plan tier. Choose encoding when the goal is defeating search, and encryption when the goal is making the literals expensive to extract in bulk.