Guides for protecting production JavaScript

Two directive styles

Pick the style that matches whether most of the file should be protected (skip a few regions) or most of the file should be left alone (protect a few regions).

Both markers also accept the block-comment form, e.g. /* javascript-obfuscator:disable */, for contexts where a line comment is awkward.

Skip a region

Use when most of the file should be protected but a small region must ship readable — a license header, a public API surface other code reflects on by name, or a third-party snippet you are not allowed to modify.

// app.js
export function chargeCard(token) {
  // ... protected business logic ...
}

// javascript-obfuscator:disable
// This block is shipped exactly as written.
window.MyWidgetPublicAPI = {
  version: "3.2.0",
  mount: mountWidget,
  unmount: unmountWidget
};
// javascript-obfuscator:enable

export function settle(order) {
  // ... protected again ...
}

Run it:

npx jso-protector --config jso.config.json --honor-conditional-comments

Or set it once in jso.config.json:

{ "honorConditionalComments": true }

Protect only a region

Use when most of the file is framework glue or generated boilerplate and only a small core deserves protection — a license check, a fraud rule, a proprietary algorithm.

// licensing.js
import { readClock } from "./platform";   // left readable

// javascript-obfuscator:protect-begin
function verifyLicense(sig, payload) {
  // ... the only part worth protecting ...
}
// javascript-obfuscator:protect-end

export { verifyLicense };               // left readable

npx jso-protector --config jso.config.json --protect-marked-comments

{ "protectMarkedComments": true }

Rules the CLI enforces

• One style per file. Mixing disable/enable with protect-begin/protect-end in the same file fails with a clear error. Pick the one that means less marking.
• Markers must be balanced. An unmatched or nested region fails before any source leaves your machine — the CLI reports the file and line so you can fix it.
• Fail-safe by default. If a file contains markers but you did not pass the matching flag, the CLI stops and points at the first marker rather than silently ignoring your intent. This prevents a marked region from being protected (or shipped) by accident.
• Verbatim means verbatim. Skipped regions are spliced back byte-for-byte after protection, so identifier names other code depends on stay stable.

How it differs from VariableExclusion and named sets

Three tools, three scopes — they compose:

• Inline directives (this page) act on regions of a file and live in the source next to the code they affect.
• VariableExclusion keeps specific identifier names un-renamed across the whole build — use it when a global name must survive, not when a whole region must.
• Named configuration sets apply a different preset and options to different files by glob — e.g. maximum protection for src/checkout/**, standard for marketing pages.

A common layering: a named set selects the preset for the checkout folder, and inline directives inside one checkout file skip a public API object that other modules call by name.