VM Obfuscation
VM obfuscation transforms your JavaScript functions into custom bytecode that runs on a virtual machine embedded in the output, so the protected logic no longer ships as readable JavaScript.
VM protection applies to eligible functions. In root mode, vmWrapTopLevelInitializers can also wrap eligible initializers for virtualization; current VM presets enable it. Review coverage warnings such as VMNoFunctionsToVirtualize, and use comment mode to select sensitive functions explicitly.
Obfuscation raises the cost of reverse engineering without making it impossible, so keep secrets and authoritative security decisions on the server - see Best Practices for what obfuscation can and cannot guarantee.
Need help? If VM obfuscation misbehaves, see Diagnosing VM Runtime Errors for how to narrow it down and file a bug report.
In this section
Runtime Compatibility
Match the build to where it runs: the Target option, runtime defenses, and what the build pipeline must preserve.
How VM Transforms Code
What the VM keeps visible vs. hides, and how to protect function names.
Targeting Specific Functions
Selectively VM-obfuscate only sensitive functions for optimal performance.
Register-Based VM
Switch the VM to a register-based execution model for faster runtime, at the cost of a slightly larger bundle.
Async Executor
Run the VM asynchronously so the bytecode decryption key can be fetched at runtime instead of shipping in the bundle.
Strict Mode Compatibility
Declare strict mode so the VM compiles correct bytecode.
Direct eval Behavior
Why direct eval() disables VM obfuscation, and how to avoid the pitfall.
VM Self Defending
Tamper detection, code integrity checks, and anti-hooking for the VM runtime.
VM Debug Protection
Anti-debugging measures for VM-protected code.
VM Domain Lock
Restrict the obfuscated VM code to specific domains and subdomains.
Browser Environment
Declare how your production build is served so the protected code can bind its integrity to it.