Compressor

What it does

This option stores the final script in a packed form and adds a small bootstrap that rebuilds the code when the file runs. The wrapper adds roughly 1.3 KB of extraction logic, so it is a net loss on small files and a net win on large ones.

Instead of leaving the transformed code visible, the output becomes a compact wrapper around packed data:

(function () {
    var packed = "...";
    var source = unpack(packed);
    execute(source);
})();

Configuration

{
  "options": {
    "SelfCompression": true,
    "CompressionRatio": "Auto",
    "SelfCompressionMinSize": 4096
  }
}

Leave CompressionRatio on Auto unless you have measured a reason not to. Set SelfCompressionMinSize whenever you protect many files of mixed size.

Content Security Policy: this option requires unsafe-eval

The bootstrap rebuilds your code from a string, which means it calls into eval and new Function. Under a strict CSP that omits unsafe-eval, the packed file will not run — you will see a CSP violation and a blank feature, not a JavaScript error you can trace to your own code.

This is worth stating plainly because it is the exception to the general rule. The rest of the engine's transforms — name mangling, string tables and encoding, control-flow flattening, member indirection — emit ordinary code and run fine under a strict CSP with unsafe-eval off. Only two features need the weakening:

• SelfCompression (this page).
• ReorderCodeEval — see Code Transposition Eval.

If keeping unsafe-eval off matters more than packing — and for most teams it should, since it is one of the highest-value restrictions a CSP can carry — leave both options off and get your size win from transfer compression instead. The full discussion is in does obfuscation break Content Security Policy.

It is probably not the size win you want

Compression here happens inside the file, which is a different thing from compression on the wire. If your server already sends Content-Encoding: gzip or br — and it should — then your users already receive a compressed payload, and packing the file first mostly gives the transport less redundancy to work with.

In exchange for a smaller number on disk you take on: 1.3 KB of bootstrap, an unpack step on every page load before your code runs, and the CSP requirement above. Measure the gzipped size both ways before concluding this option helps. There are real cases where it does — a file served without transport compression, an embedded or offline context, a single-file distribution — but "smaller bundle" on a normally configured web server is usually not one of them.

Interaction with other options

• Code Formatter is ignored. Formatted output is pointless inside a packed wrapper, so WriteFormats has no effect when this option is on.
• Encode Strings overlaps. Packing already hides literals from a plain text search, so the two do not add up. Enabling both is harmless but do not count it twice.
• Verify strict-mode behavior. A leading "use strict" is a directive only when it is the first statement in its scope, and packing rewrites the top of the file. If your code depends on strict mode, assert that dependence in a test that runs against packed output rather than assuming it survives — see does obfuscation preserve use strict for why this class of bug is silent.
• Debugging gets harder. Stack traces point into the reconstructed code, so line numbers do not correspond to anything you can open. Use unpacked builds for investigation, and keep the identifier map for symbolication.