Use this page to decide which JavaScript Obfuscator workflow fits your source-handling requirements: hosted API, online tool, npm automation, or desktop/local workflow.
Fast workflow decision
Quick evaluation
Use the online obfuscator for short samples where uploading test code is acceptable. |
Repeatable release automation
Use the npm CLI, language clients, or build plugins when protected output must be generated the same way in CI. |
Local source-handling requirement
Use the Windows desktop app when a project policy requires source to remain on the workstation. |
Security review packet
Use source-free manifests, payment-page evidence, runtime exports, and VM proof packets for reviewers instead of sharing source code. |
For the public buyer-proof map across runtime monitoring, payment-page evidence, VM proof, and local processing, start with the Security Evidence hub.
Hosted API and npm workflows
The npm CLI, Node API, and build plugins send matched JavaScript file contents or emitted JavaScript chunks to the configured HttpApi.ashx endpoint. API credentials should be read from environment variables or CI secrets, not committed into config files.
Dry run
--dry-run does not call the API. Use it to review matched files and output paths. |
Validate config
--validate-config checks config shape, paths, budgets, and option names without sending source code. |
Doctor
--doctor checks credentials presence, paths, file matching, and output readiness without sending source code. |
Release check
--release-check combines validation, dry-run planning, and doctor checks as one CI preflight report. Add --strict when warnings should fail CI. |
API check
--release-check --check-api or --doctor --check-api sends a tiny generated jso-doctor.js sample to verify credentials and endpoint health. |
Protection
CLI, Node API, and build plugins send selected JavaScript source or emitted chunks to the configured endpoint. |
Print config
--print-config --json redacts credentials as [set] or [missing]. |
Manifest
Release manifests contain file names, paths, byte counts, and SHA-256 hashes. Treat them as release metadata. |
Local-only message
--local-only --json prints the desktop/local workflow guidance and exits without reading project source. |
Marked HTML
--parse-html sends only marked <script data-javascript-obfuscator> blocks to the API and preserves unmarked HTML locally. |
When source files contain javascript-obfuscator:disable markers, the npm CLI fails by default. Pass --honor-conditional-comments only when you want enabled regions sent to the API and disabled regions preserved locally.
Desktop and local workflows
Use the desktop/local workflow when a project policy requires source to remain local, when a non-Node user needs a GUI, or when you are processing larger mixed-file projects outside a package-script pipeline.
The npm CLI can still run local preflight commands such as --validate-config, --dry-run, --doctor, --release-check, and --local-only. Actual npm CLI protection uses the hosted HTTP API.
The desktop app is the recommended path for procurement language such as "source stays on the user's workstation." The hosted API, online tool, and npm protection run send selected JavaScript to the configured endpoint; the local preflight commands above do not.
Source maps
Source maps can reveal original source after protection. The npm CLI excludes source maps by default, and bundle plugins remove stale JavaScript source maps by default. Keep that behavior for protected release artifacts unless another secure release step handles maps.
Release manifests
Release manifests contain project metadata, file names, source and output paths, byte counts, SHA-256 hashes, and processing metadata for virtual API items. Store them with release artifacts only when your release process allows path, hash, and processing metadata.
When a reviewer needs evidence without source, share the generated report or evidence packet first. For payment pages, pair the manifest with approved script inventory, header snapshot, runtime incident export, and PCI DSS v4 evidence. For VM beta builds, pair it with the VM proof pack and smoke-test result.
Credential handling
Store JSO_API_KEY and JSO_API_PASSWORD in local environment variables, encrypted CI secrets, or your organization's approved secret manager. Rotate API credentials if they are pasted into logs, chat, tickets, or build output.
For website operators, keep Web.config out of source snapshots and updated-files zips. The deployment checklist for admin password hashes, webhook enforcement, AI spend caps, and archive exclusions is in Deployment Hygiene.
CI release practices
- Run
--release-check --json before sending source code, and add --strict when validation warnings should fail CI.
- Protect into a separate folder such as
dist-protected.
- Publish protected artifacts, not the unprotected build folder.
- Use
include and exclude to skip vendor bundles, polyfills, and framework runtime files.
Support and review boundaries
Support and external reviewers should receive source-free evidence first: BuildID, plan, enabled options, manifest hashes, runtime incident IDs, dashboard export JSON, proof-pack output, and smoke-test results. Do not attach original source, protected output, source maps, API passwords, collector tokens, AI provider keys, payment-card data, customer personal data, or secrets unless your own security process explicitly allows it.
JSO is a JavaScript protection workflow. It can provide protected-output evidence, runtime first-triage data, and payment-page release artifacts, but it does not replace a managed SOC, SIEM retention system, Webpage Integrity operations platform, or native mobile app-shielding product.