What actually counts as “VM protection”
Vendors use the term inconsistently, which is the first thing to untangle. Three things commonly get the label, only one of which is a real VM:
- Control-flow flattening with self-defending wrappers. Original branches are replaced with a state-machine dispatch; integrity checks detect tampering. Strong, polymorphic when done well, but no separate opcode interpreter exists. Static analyzers can still recover semantics with effort.
- Layered runtime decoders + encrypted constant pools. Constants only exist in memory after a runtime decoder runs. Strong against static analysis, weak against an attacker willing to run the code in a sandbox.
- Real bytecode virtualization. A custom opcode set is defined per build; the source function is compiled to those opcodes; a JS interpreter dispatches them at runtime. The function’s original structure is gone; what ships is opcodes that only the VM understands.
Only the third is what JSO v3.2 ships under UseVMProtection. The first two have been part of Maximum mode since 2024 and are useful protection on their own — they’re what most paid customers actually run today — but they’re not the same protection class as bytecode virtualization, and they shouldn’t be marketed as if they were.
Cloud-VM commercial: Jscrambler
Cloud-VM Commercial
Jscrambler
What they ship: Code Transformations (renaming, string encryption, control-flow flattening), Code Annotations (per-region opt-in for stronger protection), Self-Defending (anti-tamper, anti-debug), and Threat Monitoring (runtime telemetry with a dashboard). The polymorphism story matches what JSO does in Maximum mode; the threat monitoring story has no JSO equivalent.
Where they sit on real VM virtualization: their public material describes "Code Transformations" with control-flow flattening and self-defending wrappers; named bytecode virtualization on the top tier is mentioned in select material but the public docs don’t fully describe an opcode interpreter. Treat this as “VM-class transforms with selective per-region annotation” rather than confirmed bytecode virtualization until your evaluation contract.
Pricing: not published. SMB tier is reportedly around $325 per month for limited transforms; Enterprise tier is sales-led with an annual contract.
Where they win: the threat-monitoring layer is genuinely useful for SaaS teams that want a dashboard of runtime tampering events. JSO does not ship that.
Where JSO wins: per-month published pricing including selective virtualization, opt-in via comment marker, no sales call required.
Heavy-DRM enterprise: Verimatrix and Digital.ai
Heavy-DRM Enterprise
Verimatrix Code Protection (formerly WhiteCryption)
What they ship: mature bytecode virtualization originally built for native code, ported to JavaScript. Annotation-driven selective protection. Used in payment, broadcast video DRM, and conditional-access modules where adversaries spend months on a single asset.
Pricing: sales-only. Public references suggest annual contracts in the five- to six-figure range, with multi-year terms standard.
Where they win: real depth on the virtualization. The opcode interpreter and obfuscation layered on top of it have been hardened against professional reversers for a decade in native form. Their JS port inherits that pedigree.
Where JSO wins: we’re not trying to win here. If your asset justifies a six-figure annual contract for protection, Verimatrix is a credible option. JSO is for the band of customers protecting commercial JavaScript — SaaS dashboards, license validation, business logic — where six figures isn’t justified but free obfuscation isn’t enough.
Heavy-DRM Enterprise
Digital.ai Application Protection (formerly Arxan)
What they ship: a full anti-tamper / anti-reverse-engineering suite with modules for native, mobile, and JavaScript. JS module is one component; their depth is greater on the native side. Bytecode virtualization is part of the offering on top tiers.
Pricing: sales-only. Enterprise-only customer list (banking, gaming, broadcast).
Where they win: if you’re protecting a multi-platform application (native + mobile + web) and want one vendor for all of it, Digital.ai is built for that. Their runtime monitoring across platforms is mature.
Where JSO wins: JS-only commercial scope. We don’t protect Android or iOS binaries; we don’t aspire to. If you’re shipping browser JavaScript and want protection priced like a SaaS, JSO is what that looks like.
Static-transform competitors
The widest group of products labeled “VM” or “virtualization” in marketing copy actually ship aggressive static transforms. They’re still useful protection — especially against casual reverse engineering and pattern-matching deobfuscators — but they’re not in the same protection class as a real bytecode interpreter.
Static-Transform Commercial
PreEmptive JSDefender
What they ship: Control Flow Obfuscation, String Encryption, Eval Manipulation, Anti-Tampering. Self-hosted and cloud delivery options. Strong .NET-ecosystem positioning (same vendor as Dotfuscator).
Where they sit on real VM virtualization: their public docs describe transforms; we have not seen a documented bytecode interpreter in the public feature list. Treat as a static-transform product with self-defending wrappers.
Pricing: quote-only.
When to pick them: if your shop already runs PreEmptive Dotfuscator on .NET assemblies and you want one vendor for both, JSDefender is a sensible extension. If you’re only protecting JS, this isn’t a clear differentiator.
Open-Source Static
obfuscator.io / javascript-obfuscator (npm)
What they ship: the most-used open-source JavaScript obfuscator. controlFlowFlattening, stringArrayEncoding, deadCodeInjection, renameProperties. Public playground at obfuscator.io.
Where they sit on VM virtualization: the README explicitly says they do not include bytecode virtualization. The transforms are static-only.
Pricing: free / MIT.
When to pick them: when free is the requirement, or when you want code-level integration with a Webpack/Rollup plugin that JSO doesn’t currently ship. Their playground is excellent for trying transforms quickly.
Where JSO wins: per-build polymorphism in Maximum mode, the upcoming v3.2 VM virtualization, embedded-JS support (HTML, ASPX, JSP), the desktop batch workflow, and a paid-account pipeline with usage tracking.
Open-source virtualizers
A small number of open-source projects do ship real bytecode virtualizers. They’re instructive references, but they ship as code, not as products — you bring your own build pipeline, performance benchmarking, and production-readiness work.
Open-Source Virtualizer
js-virtualizer (aesthetic0001, December 2024)
What it ships: a focused JS-to-bytecode virtualizer, ~313 KB, MIT-licensed. Compiles a function to opcodes; emits a JS interpreter that runs them at runtime. Uses acorn for AST parsing, escodegen for emit, js-confuser for the post-virtualization obfuscation pass.
Pricing: free / MIT.
When to pick it: as a study reference, or as the basis for an in-house virtualization layer if you’re willing to do the production hardening yourself. It’s the most usable open-source bytecode virtualizer in 2026; we’ve verified it works end-to-end on JSO-style functions.
What it’s missing: per-build polymorphism (the dispatcher shape is fixed), browser bundling adapter (output uses Node require), tier integration with a SaaS, and async/await support. Production-grade integration is the work; the virtualizer itself is solid.
Open-Source Virtualizer
KProtect (yang-zhongtian)
What it ships: a stack-based VM written in TypeScript, inspired by VMProtect and RISC architecture. Bundle format is JSON: {strings: [...], bytecode: <compressed opcodes>}. Has a CLI, packages, and a test harness.
License: GPL-3.0-or-later. This matters: GPL-3.0 is incompatible with proprietary distribution, including the JavaScript output you ship to customers. Commercial integration of KProtect’s source is not legally clean; the project’s own README also says “experimental and SHOULD not be used in any production environment.”
When to pick it: as a reference for VM design discipline (the layered approach to opcode encoding is well-organized). Not for commercial integration without a clean-room reimplementation or a license change.
Where JSO v3.2 actually lands
Across the seven axes that buyers actually weigh, this is what you can defend in a sales conversation:
| Axis |
JSO v3.2 |
Closest competitor |
| Real opcode interpreter (selective) |
Yes — // @virtualize marker |
Jscrambler (annotations on top tier), Verimatrix, Digital.ai |
| Per-build polymorphic VM |
Yes — opcodes, dispatcher, XOR key regenerate per build |
Jscrambler claims it; OSS virtualizers do not |
| Per-month pricing including VM |
Yes — $49/mo Corporate, $99/mo Enterprise |
None of the named commercial competitors publishes VM-tier prices |
| Selective per-function (opt-in) |
Yes — comment marker |
Jscrambler annotations; Verimatrix and Digital.ai annotation-driven |
| Async / await in virtualized code |
Not in v3.2 — skipped with engine warning |
Heavy-DRM tools handle it; static-transform tools don’t need to |
| Runtime threat monitoring / live alerts |
Not part of the offering — pair with a monitoring vendor |
Jscrambler, Verimatrix, Digital.ai |
| Free playground exposing the VM output |
No — VM is paid-tier only; Maximum mode (everything else) is free |
OSS virtualizers; obfuscator.io for non-VM |
Honest limits to keep in the room
Three things to be honest about when an evaluator asks:
- Verimatrix and Digital.ai have deeper virtualization than what JSO ships. A decade of native-code VM hardening, ported to JS, is real. We’re not trying to match it. We’re trying to make selective virtualization available at a price-point that doesn’t require a six-figure budget approval.
- Jscrambler’s threat-monitoring layer has no JSO equivalent. If your security model includes “know when someone is attacking the protected output,” that’s a different product category. JSO output is silent; it doesn’t phone home. For some teams that’s a feature; for others it’s a missing capability.
- Async/await isn’t supported in v3.2 virtualized code. The marker on an async function is detected; the function is skipped with an engine warning rather than failing the build. Promise-chain transformation is on the v3.3 roadmap. If your hot security-critical code is async-heavy, today is not your day.
A decision framework
One question to start with: what’s the budget per protected function?
- $0. Use the open-source
javascript-obfuscator npm package. Get name mangling, control-flow flattening, string encoding. Don’t expect bytecode VM.
- $29–$99 per month. JSO. Maximum mode (per-build polymorphic transforms) on every paid tier; selective VM virtualization on Corporate and Enterprise. Per-month, no sales call.
- Five-figure annual budget. Jscrambler is the most credible option in this band. Get the threat-monitoring layer if your security team will use the dashboard.
- Six-figure annual budget. Verimatrix Code Protection or Digital.ai Application Protection. Real depth on the virtualization, sales-led evaluation, multi-year contracts, used in payment / broadcast / anti-cheat.
One bit of free advice: evaluate competitors on the same code you’ll actually ship, not on a synthetic benchmark. The 80× runtime cost figure JSO publishes for virtualized code is for cold paths; if you mistakenly virtualize a 60 fps render loop, no vendor’s tooling will save you. Selective virtualization is the right discipline regardless of which vendor you pick.
Next steps
If you’re evaluating JSO specifically, the practical path:
- Read the VM Protection docs for the API contract and the
// @virtualize marker syntax.
- Read the roadmap article for the design rationale and the ~80× runtime-cost framing.
- Sign up for the Corporate or Enterprise tier to get the flag accepted today (it currently emits a preview warning — the virtualizer itself activates in v3.2).
- Email [email protected] to be on the v3.2 private beta list.
All vendor characterizations in this article are based on publicly available material as of April 2026. Vendor product capabilities and pricing change — for current claims, check each vendor’s site. Trademarks belong to their respective owners.