Online tool Best for quick evaluation, smaller scripts, and option reviews. Use it when a browser workflow is acceptable and you want immediate output.
Advanced team integrations Best for repeatable releases that already have a technical owner. Keep hosted credentials in environment variables or release-tool secrets instead of committed config.
Desktop and local review Best when source must stay local, when you protect embedded JavaScript in mixed files, or when a non-Node user needs a visual project workflow.
Preflight checks Review settings before protection so missing credentials, bad paths, or option drift fail early.
Compatibility rules Protect generated JavaScript after bundling, preserve public names, and skip vendor or runtime files that do not need obfuscation.
Release metadata Use protected-output folders and release notes when operations teams need a reproducible release record.
Local fallback Move the release into the desktop app when mixed content, embedded scripts, or local-only review matters more than automation speed.
Vite, Webpack, Rollup, esbuild Protect generated chunks after bundling so bundlers stay responsible for code splitting, tree-shaking, and framework compilation.
React, Vue, Angular, TypeScript Protect the JavaScript they emit, then preserve public symbols, hydration hooks, and SDK-facing entry points with deliberate exclusions.
Advanced team automation Use release-tool secrets, shared settings, and protected-build smoke tests when protected output becomes part of a standard deployment process.
Mixed-file desktop path Move into the desktop app when a release includes HTML, PHP, ASP, ASPX, JSP, or embedded script blocks that need a local review path.
Two decades of releases JavaScript Obfuscator has been shipped under the same product line since 2004, with a focus on practical code protection that has tracked changes in JavaScript itself.
Named company RichScripts Inc. publishes its address, support contact, terms of service, privacy policy, and the local-versus-hosted workflow expectations used during evaluation.
Documented client base The clients page documents the breadth of teams that have shipped with JavaScript Obfuscator over the years — useful context for buyers running their own evaluation.
GDPR / CCPA — data minimisation Submitted JavaScript is processed in server memory only. Temporary upload artefacts are removed after the obfuscation request completes. The desktop workflow keeps source on the workstation so source code never leaves the operator’s control. Both align with the data-minimisation expectations reviewers cite under GDPR Art. 5 and CCPA §1798.100.
OWASP ASVS / Top 10 Maximum mode helps reduce the value of intercepted client-side bundles by making public JavaScript harder to read and tamper with. Obfuscation should be paired with server-side authority; we recommend it as a layer, not the only control.
PCI DSS — in-scope client code For payment pages or scripts near cardholder data, reviewers often ask how client-side script changes are controlled. JavaScript Obfuscator can support a release process where protected output is reviewed, tested, and monitored before it ships.
HIPAA — PHI-adjacent web apps For health-information apps where JavaScript touches sensitive workflows, the desktop app supports local-only processing so source can stay inside an already governed workstation environment.
NIST SSDF (SP 800-218) The desktop workflow and optional technical integrations let teams review protection settings and make protection a deliberate release step instead of an ad hoc action.
Audit notes for reviewers We do not currently hold an independent SOC 2 or ISO 27001 attestation. What is published instead: source-handling behaviour, release-validation expectations, support and contact channels, and the local workflow path for projects that need code to stay on a workstation throughout. Buyers running a formal review can request the same in writing.
Reviewed shared baseline Keep one desktop project, exported JSON preset, or jso.config.json file as the reviewed baseline so releases start from the same option set.
Credential discipline Store hosted credentials in release-tool secrets or environment variables and keep validation steps close to the process that builds and tests protected output.
Release evidence Use compatibility checks, release notes, protected-output folders, and smoke tests as evidence when engineering or procurement wants repeatable release review.