Reference

The vocabulary of JavaScript protection, defined once.

Obfuscation documentation is full of words that vendors use differently — and a few that are used to mean more than they deliver. This is a plain-English definition for each term you will meet on this site or in a competitor’s option list, with a link to the page that explains the mechanics and, where relevant, an honest note about what the technique does not do.

Try Online Obfuscator Full Documentation

How To Read This

Transform, defense, or diagnostic?

Almost every term falls into one of three buckets, and confusing them is the most common source of bad protection decisions.

TransformsChange the artifact. Cost: size and sometimes speed.

Runtime defensesChange behaviour when tampered with. Cost: false positives.

DiagnosticsLet you support what you shipped. Cost: nothing, if you keep the maps.

Foundations

The words that get confused most often

If you only read one section, read this one. Most disagreements about whether obfuscation “works” turn out to be disagreements about these five definitions.

Obfuscation

A set of meaning-preserving rewrites that make code expensive for a human to understand while leaving its behaviour unchanged. It raises the cost of comprehension. It does not make code secret, and it never makes a value unrecoverable — anything the program can compute, an analyst with a debugger can observe.

Minification

Size reduction: whitespace and comments removed, local variables shortened. A formatter restores readability completely because minification never removed any information a reader needs. Useful, universal, and not a security control — the long version is minification vs obfuscation.

Encryption

Making data unreadable without a key. Client-side JavaScript cannot be encrypted in any meaningful sense, because the browser must be given both the ciphertext and the key to run it. What vendors call “encrypted strings” is encoding with a decoder attached — see obfuscation vs encryption.

Deobfuscation

Recovering intelligible code from a protected artifact. Formatting is trivially recoverable; original identifier names and original control flow are not, because that information was destroyed rather than hidden. What is realistically recoverable is covered in is obfuscation reversible.

Reserved name

A name you tell the protector never to rename, because something outside the protected code matches it as a string — an API field, a storage key, a template binding, a public SDK method. Managing this list is most of the real work; see the variable exclusion list.

Hot path and cold path

Code that runs thousands of times per second versus code that runs once. The distinction decides where expensive transforms are affordable: protect a licence check hard, leave a render loop light. This single idea resolves most performance objections.

Transforms

What each rewrite actually does

These change the artifact you ship. Each one buys a specific kind of unreadability and charges a specific price in bytes, speed, or compatibility risk. Every entry links to its full option page.

Name mangling

Declared identifiers become short generated names. Nearly free, and the foundation everything else sits on. Safe wherever a reference was resolved at compile time. Name mangling ›

Member renaming

Property names renamed consistently across a whole project. Powerful and the riskiest option in the set, because a renamed property is a different property to every consumer. Opt in by rule. Protect members ›

Member access hiding

Rewrites obj.value into a computed lookup without changing the key itself — the readability win of renaming with none of the interface risk. Move members ›

String array

Literals move into one table; each use becomes an index lookup. Searching the bundle for an error message no longer lands you in the function that raises it. Move strings into array ›

String encoding

Literals stored in a transformed representation and decoded on use. Defeats plain-text search of the bundle; does not defeat a breakpoint on the decoder. Encode strings ›

String encryption

A stronger variant with a generated decoder that differs per build. Same honest ceiling as encoding: the key ships with the code, so this raises cost rather than conferring secrecy. Encrypt strings ›

Control flow flattening

Sequential and branching code becomes a dispatcher loop over a state variable. Reading order stops matching execution order, which is what makes a beautified dump unhelpful. Flat transform ›

Code transposition

Statements and functions are reordered so that physical position carries no information about program order, with the original order restored at runtime. Code transposition ›

Nested function movement

Inner functions are lifted out of their enclosing scope so the visual nesting that documents your design is gone from the artifact. Move nested function ›

Global replacement

Renames global identifiers project-wide. A cross-file decision one scope up from member renaming, and one that needs the same explicit thinking about external callers. Replace globals ›

Object declaration protection

Hides the shape of object literals — how many keys, in what order, with what nesting — without changing key names, so no interface is affected. Protect object declaration ›

Self-compression

The protected program is compressed and unpacked by a small stub at load time. It is one of only two options that emit eval, which matters if you run a strict Content Security Policy. Compressor ›

Bytecode virtualization

Selected functions are compiled to a custom instruction set run by an embedded interpreter. The strongest transform available and the slowest — scope it to licensing and entitlement logic. VM protection ›

Deep obfuscation

A composite mode that applies the aggressive transforms together rather than one at a time, for code where comprehension cost matters more than artifact size. Deep obfuscation ›

Inline directive

A comment in your source that turns protection on or off for a specific region — the practical way to protect the module that holds the asset and leave the public surface readable. Inline directives ›

Runtime Defenses

Terms that describe behaviour, not appearance

These do not make code harder to read. They make a tampered copy behave differently from an untampered one — which is a separate goal with a separate failure mode, namely false positives against honest users.

Self-defending

Output that stops working correctly if it is reformatted or edited, by tying execution to properties of the exact emitted text. Reformat the bundle and it breaks rather than explaining itself.

Debug protection

Code that detects an attached debugger and makes stepping impractical. It raises the cost of dynamic analysis; it cannot prevent it, since the analyst controls the runtime. Runtime defense ›

Domain lock

The bundle refuses to run unless the page origin matches an allowed list. Useful against casual redistribution of a licensed widget, trivially removable by anyone editing the bundle — which is exactly why it pairs with tamper detection.

Tamper detection

A check that the shipped artifact is byte-for-byte what you built. Its value is not blocking the edit but knowing about it — a modified copy that reports in is an incident you can act on.

Watermarking

An identifier embedded in a build so a leaked copy can be traced to the licensee it was issued to. Deterrence and attribution rather than prevention. Watermark demo ›

Environment integrity

Signals about the page the bundle is running in — injected scripts, unexpected origins, modified globals — reported so you can distinguish a supply-chain problem from a bug. Environment integrity ›

Build & Diagnostics

Terms from the pipeline around protection

These are not transforms, but they decide whether protection is operable in a real release process. Getting them wrong is the usual reason a protected build is abandoned after one incident.

Polymorphic output

The default: the same input produces a different artifact every build, so a signature written against one release does not match the next. It is also why your output hash changes when nothing else did.

Seeded (reproducible) build

Supply a seed and the same input, options and seed produce byte-identical output. What you need for build attestation and for diffing two releases — and explicitly not a security control. Reproducible builds ›

Identifier map

The private record of which original name became which generated name in one specific build. Keep it, never publish it, and store one per release — without it, supporting protected code is guesswork.

Symbolication

Translating a production stack trace back into original names using that map, locally. The reason protected code stays debuggable at all. Symbolication ›

Source map

A file mapping generated code back to source. Invaluable in development and catastrophic in production if published beside the bundle — it undoes the protection completely. Source maps ›

Tree shaking

A bundler dropping exports nothing references. Protection that turns member access into computed lookups defeats the analysis it depends on, which is why protection runs after bundling. Build order ›

Subresource Integrity

An integrity hash on a script tag that the browser verifies before executing. Compute it from the protected file, not the pre-protection one. SRI and obfuscation ›

Code splitting

Emitting several chunks loaded on demand. Protect them in one pass so generated names agree; protecting chunks separately gives each its own naming decisions. Code splitting ›

Directive prologue

A literal like "use strict" that only takes effect as the first statement of a file or function body. Rewrites that displace it silently change semantics. Use strict ›

Compatibility validation

Checking that protected output parses and behaves like the input before it reaches users. The cheapest possible insurance against a transform meeting an unusual construct. Compatibility validation ›

Resistance score

A measured estimate of how much a protected artifact resists automated analysis, used to compare option sets rather than to make an absolute claim. Scorecard ›

Mixed file

A file that is not pure JavaScript — server markup, template tags, or HTML wrapped around script. It needs a protector that can find the script regions and leave everything else byte-identical.

Next Step

See the terms applied to real code

Definitions only get you so far. Paste a file into the online obfuscator, switch one option at a time, and watch which words above describe what changed.

Try Online Obfuscator › Transforms Side by Side

Where to go from a definition

Every transform explained · Protecting JavaScript (overview) · Comparing obfuscators · Configuration cookbook · Full documentation