Encrypt Strings stores string values in an encoded form and rebuilds them through generated logic when the script runs. Unlike Encode Strings, which is a fixed respelling any beautifier reverses, recovering these values means running or emulating the generated decoder.
What changes
Instead of leaving a readable literal in the file, the value is stored encoded and reconstructed at the point it is needed. A readable string such as:
"license-expired"
may become a generated representation similar to:
"nsf%y%tlcrludli%eBeolvrrs%..."
The decoder that turns that back into your string is itself generated per build and is subject to the other transforms you have enabled, so it does not appear as a recognisable, reusable helper across releases.
How it differs from Encode Strings
| EncodeStrings | EncryptStrings |
|---|
| Mechanism | Escape-sequence respelling | Encoded value plus generated runtime decoder |
| Recovered by a beautifier | Yes, automatically | No — requires running or emulating the decoder |
| Runtime cost | None (resolved at parse time) | Work per string read |
| Plan | Free | Enterprise |
They are not exclusive, and there is no benefit to reaching for the weaker one when you have the stronger available for the strings that matter.
Be precise about the attacker model
The option name says "encrypt", and it is worth being exact about what that does and does not mean here. The decoder ships in the same file as the data it decodes. Anyone who can run your code can run the decoder, and a determined analyst can extract every string by instrumenting the decode function and collecting its return values.
So what this option raises is cost, not certainty. It removes static extraction from the table of cheap attacks and replaces it with dynamic extraction, which needs a working harness, a runtime, and time. For most commercial threats — a competitor copying a pricing rule, a scraper looking for endpoints, a cheater looking for a validation message — that difference matters. Against an attacker willing to instrument your bundle, it does not.
The corollary: a value that must stay unknown to the user does not belong in shipped JavaScript under any option. Move it behind an API call. See you cannot hide an API key in JavaScript for the reasoning, and obfuscation vs encryption for why client-side "encryption" of shipped code is a different thing from encryption in transit or at rest.
Configuration
{
"options": {
"MoveStrings": true,
"EncryptStrings": true
}
}
From the open-source javascript-obfuscator package, the stronger values of stringArrayEncoding map to EncryptStrings rather than EncodeStrings. See npm migration.
Use reservedStrings to hold specific literals out. Anything another system matches on byte-for-byte — a protocol constant, a selector, a webhook path — must be reserved, because a reconstructed value is only equal at runtime, not in the source text other tools read.
Runtime cost and where to spend it
Because values are reconstructed rather than parsed, every read does work. That is invisible in ordinary UI code and very visible in a hot loop that touches strings per frame or per row.
- Profile before and after on the paths that matter: render loops, per-row formatters, game update ticks, large-list virtualisation.
- Scope it rather than applying it everywhere. Named configuration sets let you run maximum protection over
src/licensing/** and a lighter preset over the rest; inline directives narrow it further to regions within a file.
- Hoist hot reads in your own source. A string read once into a local and reused in a loop pays the decode cost once.
- The measured cost of each transform family is discussed in does obfuscation slow down JavaScript.
Tip: this option earns its cost on strings whose content is the asset — licence states, rule names, internal endpoints, gating messages. It earns nothing on UI copy a user reads on screen anyway. Apply it narrowly and measure; blanket application is the usual reason a protected build feels slower than it needs to.