Advanced Team Integration

Connect JavaScript Obfuscator to a repeatable release process.

jso-protector is the optional package for teams that already have release automation. Start with the online tool or desktop app to choose settings, then use this package when protection must run the same way every release.

Download Package Workflow Docs
Best Fit

Use it after settings are proven.

jso-protector runs on a team machine or release runner, protects selected JavaScript through the hosted JavaScript Obfuscator service, and writes the protected files to a release folder.

WebsiteBest for quick browser-based protection and settings review.
DesktopBest for GUI setup, mixed files, and local/manual project workflows.
jso-protectorBest when protected releases need to run automatically.
What It Is

jso-protector is for teams that need repeatable protection

The website and desktop app are the easiest places to evaluate JavaScript protection and choose settings. jso-protector is for the next step: applying those settings automatically whenever a release is prepared.

What it does

It scans the JavaScript files your team chooses, sends them to the hosted protection service, and writes the protected versions into a separate release folder.

What it does not do

It is not a separate product, a new server, or a replacement for the desktop app. It is an automation path for the same JavaScript Obfuscator service.

Why it exists

Teams that ship often need protection to happen the same way every time. jso-protector gives them that repeatable path without changing the account, plan, or service behind the protection.

How It Fits

One product, three entry points

Think of jso-protector as the advanced entry point in the same product family. Customers choose the workflow that matches how they work, while accounts and protected-output rules stay centralized.

Workflow Best For What The User Does
Online tool Quick samples, setting review, product evaluation, small manual jobs. Paste or upload JavaScript in the browser, tune settings, inspect output, and validate the protection profile.
Desktop app GUI-driven batch jobs, mixed-file projects, and larger manual release projects. Protection uses the hosted service. Open the desktop app, configure protection visually, process larger projects, and use command generation when needed.
jso-protector Automated releases, build-owner workflows, and projects that already have a repeatable build process. Install the package, point it at the built JavaScript, run it after build, and publish the protected output folder.
Example protected job shape
{
  "APIKey": "dashboard-api-key",
  "APIPwd": "dashboard-api-password",
  "Name": "release-job",
  "MixedServer": false,
  "Items": [
    {
      "FileName": "app.js",
      "FileCode": "..."
    }
  ],
  "OptimizationMode": "Web",
  "EncodeStrings": true
}
Trust Model

The account controls still stay with the service

  • Plan limits, billing, and account enforcement stay on the server.
  • Dashboard API credentials stay required for real protection jobs.
  • The hosted protection service decides whether a request succeeds or fails.
  • The local package only prepares files, credentials, and selected options for the protection job.
Why Teams Want It

The benefit is consistency, not a different protection engine

Teams ask for automation when protection needs to happen every release, not occasionally by hand. jso-protector keeps JavaScript Obfuscator in the same release process as testing, packaging, and deployment.

Repeatable releases

Protection becomes a standard release step instead of a separate manual task.

Team tool compatibility

Teams can run protected builds in the release tools they already use.

Framework fit

It integrates after Vite, Webpack, Rollup, Next.js, Metro, Browserify, or esbuild have already produced normal JavaScript.

Separate protected output

Protected files can be written into their own folder so reviewers can clearly see what will be shipped.

What It Supports

Built for teams that already release JavaScript often

Command workflow

Protect a folder, a single file, or stream-based input. Use preflight checks before a protected release goes live.

Custom team scripts

Release teams can call the wrapper from their own scripts when release rules need to be customized.

Modern JavaScript projects

Use it after Vite, Webpack, Rollup, esbuild, Browserify, Gulp, Grunt, Next.js, or Metro has produced normal JavaScript.

See technical commands See build integration guidance See modern JavaScript compatibility
Typical release script
{
  "scripts": {
    "build": "vite build",
    "preflight": "jso-protector --config jso.config.json --release-check --json",
    "protect": "jso-protector --config jso.config.json --manifest dist-protected/jso-manifest.json",
    "release": "npm run build && npm run preflight && npm run protect && npm run smoke"
  }
}
Typical install path
npm install --save-dev https://javascriptobfuscator.com/download/jso-protector/jso-protector-0.3.2.tgz
npx jso-protector --init
npx jso-protector --config jso.config.json --release-check --json
Security And Processing

Designed for teams that want a review step before protection runs

One common concern with hosted protection is operational control. jso-protector gives teams checks they can run before submitting a real protection job.

Validate config

Check endpoint, credentials presence, path settings, option names, and budget values without sending source code for protection.

Dry run and release-check

See which files will be protected and whether any mixed-file handling will change the job before protection begins.

Protected output records

Record protected file sizes and hashes so a release owner can verify the release output later when needed.

Security and Processing Compatibility Validation Options and Presets
Desktop vs Automation

When to choose the desktop app instead

The desktop app remains the better entry point for visual review. WinUI Local Standard protects basic ES5 .js offline; paid Local Advanced keeps modern .js/.jsx and mixed HTML/server-script source on-device after an online entitlement check. The automation package sends selected JavaScript to the hosted service by default, or protects it on the build machine with --local.

Need Use Desktop App Use Automation
Visual setup and local review Best fit
Choose options in a GUI, review projects, and work without npm knowledge.		 Possible, but not the primary experience.
Automated releases Possible through generated commands, but not the most natural entry point. Best fit
Designed for repeatable release jobs and build automation.
Mixed files and embedded JavaScript Best fit
Desktop workflows remain stronger for larger mixed-file/manual review jobs.		 Supports marked HTML/template protection in controlled workflows, but the desktop path remains the broader mixed-file solution.
Local-only policy Hosted protection
The desktop workflow sends selected JavaScript to the hosted service. Do not use current protection workflows when policy forbids that transfer.		 Best when hosted protection is acceptable under team policy.
Install Options

What release teams can download from this site

Most users should start with the online tool or desktop app. These package downloads are for teams that need a controlled install path inside an existing project or internal release process.

Project package

The standard technical-team download. Install it directly into a project and run it from package scripts or release automation.

npm install --save-dev https://javascriptobfuscator.com/download/jso-protector/jso-protector-0.3.2.tgz

Zip package

Useful for teams that want the package contents as a direct download, internal archive, or controlled handoff.

/download/jso-protector/jso-protector-0.3.2-server-upload.zip
Bottom Line

Use jso-protector when protection needs to run automatically.

It does not replace the website or desktop app. It extends the same JavaScript Obfuscator service into a repeatable release workflow for teams that ship JavaScript often.

  • Keep the hosted service as the protection backend.
  • Keep the desktop app as the GUI and local/manual workflow.
  • Use jso-protector as the advanced automation entry point.
  • Let users choose the workflow that matches how they already ship software.
Download jso-protector Read Workflow Docs See All Downloads
Frequently Asked

CLI questions, answered

What the command-line tool does, where it runs, and how it behaves in a pipeline.

Does the CLI send my source code anywhere?

It depends on the mode you choose, and the tool is explicit about which one you are in. The default mode and VM bytecode protection use the authenticated hosted service, so the selected JavaScript is transmitted under the published terms. Passing --local runs protection on your own machine instead: the plan check still happens online, but the source does not leave it. If a policy requires source never to transit, that is the mode to use, and it is worth confirming it in a dry run before wiring it into CI.

Can I run it in CI without checking a credential into the repository?

Yes, and you should. The CLI reads its credentials from the environment, so store them in your CI provider’s secret store and let the job inject them. Keeping keys out of the tree matters more than usual here, because a protection credential in a repository is readable by everyone with a clone long after the person who added it has left.

Why does the output change on every run, and how do I stop it?

Protected output is polymorphic by design, so two runs over identical input produce different bytes. That defeats artifact snapshots, bundle-size baselines and task-runner caches, which all assume stable output. Supply a seed and the same input, options and seed produce byte-identical results, so those tools work again while consecutive releases still differ from one another.

What should run on a pull request versus a release build?

Keep the expensive work off pull requests. A release-check preflight validates configuration, plans a dry run and runs the doctor checks with no API call, and a compat-scan flags name reflection and other protection-hostile patterns in the source. Together those catch most problems in seconds. Save the real protection run, the end-to-end suite against the protected artifact, and manifest verification for release branches and nightly builds.

How do I verify that what I am about to ship is what the tool produced?

Use the manifest and the release signature together. The manifest records a source and output hash for every file, and verifying it confirms nothing is missing or altered — with a source-map audit that fails the build if a map file or a sourceMappingURL comment survived. Signing the release adds an attestation over the build id and file hashes that a customer can check against your public key, which is what turns "trust us" into something they can verify themselves.

Does it work with my bundler?

There are plugins for the common bundlers, and the CLI works on a directory tree when there is no bundler at all. The important detail is ordering: protection runs on build output, after bundling and minification, so that it sees the code you actually ship rather than source the bundler is about to rewrite. Where a plugin exists it handles that placement for you.