Thin-VM transforms your JavaScript into bytecode that runs inside an embedded virtual machine. Your license checks, bot and fraud detection, and proprietary algorithms become a protected runtime that stands up to reverse engineering, static analysis, debuggers, and automated tooling. Every release is built differently.
Ordinary obfuscation renames variables, mangles strings, and wraps everything in layers of functions that call other functions, but the result is still readable JavaScript a patient attacker can trace. Thin-VM goes further: it transforms your code into bytecode that only its own embedded virtual machine can run, hardened against reverse engineering, debugging, automation, and AI-assisted analysis.
Your JavaScript compiles to bytecode that only Thin-VM's embedded virtual machine can run. Your logic never appears as readable JavaScript in DevTools or static-analysis tools, so an attacker has to reverse-engineer the whole VM before they can even start on it.
Closures, classes, async/await, exceptions, regex, iterators, prototypes. The modern language compiles cleanly to bytecode and passes 99% of test262, the conformance suite the major engines run. Your team keeps writing the JavaScript they already know.
Optional defense layers let a protected bundle detect a hostile environment and respond by degrading or serving a decoy instead of your real logic. It can spot an attached debugger or open DevTools, a tampered or hooked runtime, an automation driver, or a headless browser. Every layer is opt-in per build.
The interpreter is built for low overhead with no warm-up tax. Protected code runs fast enough for real-time paths like license gates, anti-fraud checks, and paywall logic.
Every build is structurally unique, so what an attacker reverse-engineers from one copy doesn't carry to the next. Automated and LLM-driven tools depend on reusing a single solved example across your whole distribution, and that shortcut is gone. Mint a fresh variant per download.
Output is one self-contained JavaScript bundle with the runtime and protected payload in a single file. Your customers get no extra dependencies and no build step.
Your readable JavaScript on the left, the protected bundle Thin-VM produces on the right. Both load lazily, so they never slow the page down. Hit Run VM to execute the protected bundle right here in your browser.
Loading…Loading…Generated with the L3 preset, not maximum protection, for demonstration only.
Your backend code stays on your servers, out of reach. The exposure is the JavaScript you ship to the browser, where anyone can open it. Thin-VM is made for exactly that: a sealed layer around the logic that matters, not a wrapper around your whole app.
Verify subscriptions, enforce premium-only features, and validate trial expiration in the JavaScript you ship, without handing the validation rules to everyone who runs your app.
Ship browser-fingerprinting collectors and behavioral checks inside a sealed runtime, the client-side layer that feeds your risk scoring. Fingerprinting runs in the open, where attackers read it to spoof signals and forge trusted devices, so keeping those rules unreadable means they can't be fuzzed or systematically bypassed.
The proprietary logic that runs in the browser to do its job: pricing and quote calculators, media and signal-processing pipelines, procedural generation, custom visualization engines. Keep the JavaScript IP that competes for you out of your competitors' static-analysis tools.
Browser extensions and in-browser games run inside user environments by design. Thin-VM lets you ship them without exposing the anti-cheat, validation, or proprietary game logic behind them.
The odds engine, RNG, and payouts stay on your servers, where they belong. What ships to the player is bot, cheat, and collusion detection, device fingerprinting and behavioral signals for risk scoring, geolocation-compliance collectors, and HTML5 game clients. That code runs on the player's machine, where bonus hunters, bot farms, and cheaters pick it apart. Thin-VM keeps it unreadable, so it can't be studied, spoofed, or bypassed.
Drop in your JavaScript. Get back a single self-executing file that even you would struggle to read. Four steps, fully automated.
Where Thin-VM has been, what just shipped, and what's next.
Thin-VM begins. The bytecode format, the embedded interpreter, and the compile-to-VM pipeline are built for protection, not only execution.
Native ES5 execution is validated against test262, the conformance suite the major JavaScript engines run. That locks in the baseline the rest of the language builds on.
Language support extends through ES2022, now passing 99% of test262, so protected code behaves like real JavaScript.
A suite of protection layers ships that raises the cost of reverse-engineering the VM itself, making static and dynamic analysis of a protected bundle much more expensive.
Defenses aimed at automated, LLM-driven reverse engineering, denying AI tooling the shortcuts it relies on to analyze protected code at scale.
Extending language support to the latest ECMAScript edition, so the newest JavaScript your team writes compiles to the VM without compromise.
A stronger sandbox with tighter isolation for the third-party plugins, extensions, and user scripts that run inside the apps you ship.
Tooling to manage, version, and orchestrate protected bundles across builds and deployments, so protection scales without manual bookkeeping.
Answers to the questions teams ask most before integrating.
Anything you'd rather attackers couldn't read by pressing F12: license checks, bot and fraud detection, premium features behind a paywall, proprietary algorithms, anti-cheat logic. Use it on the code worth hiding, not your whole app.
Ordinary obfuscation renames variables, mangles strings, and wraps everything in layers of functions that call other functions, but the result is still readable JavaScript running in DevTools, and a patient attacker traces through it.
Thin-VM works differently: instead of disguising your JavaScript, it transforms it into bytecode that resists reverse engineering and static analysis at a structural level. And every release is built differently from the last.
Given enough time, anything can be broken. The goal isn't perfect protection. It's making analysis expensive enough that most attackers move on to easier targets. Because every Thin-VM release looks different, what someone learns from one build doesn't shortcut the next.
Yes, that's a core design goal. Every Thin-VM build is structurally unique, so reverse-engineering one copy doesn't carry over to the next. Automated pipelines and LLM-driven analysis depend on reusing a single solved example across your whole distribution, and that reuse stops working.
Optional hardening can also detect and respond to automation drivers, headless browsers, and runtime instrumentation while your code runs.
Yes, through optional defense layers. A protected bundle can detect a hostile environment (an attached step-debugger or open DevTools, a tampered or hooked runtime, an automation driver) and respond by degrading or running a decoy instead of your real logic.
Every layer is opt-in per build, so you choose the defenses that match your deployment.
Yes. Modern JavaScript just works: closures, classes, exceptions, regex, and the rest of the syntax your team already writes. The compiler passes 99% of test262, the conformance suite the major JavaScript engines run, so your code behaves the way real JavaScript does.
The VM targets ES2022 natively. Anything newer is transpiled down to ES2022 with Babel before it compiles, so the latest syntax still works while the VM stays on one stable target.
One that matters: the protected bundle ships without the compiler, so it cannot turn new source into bytecode while it runs. eval() and new Function() work only when the source is a string literal, which is compiled at build time.
Works, the source is a literal:
eval('1 + 1');
new Function('a', 'b', 'return a + b');Does not work, the source is a variable built at runtime:
const code = '1 + 1';
eval(code);
const body = 'return a + b';
new Function('a', 'b', body);Everything else in the modern language runs as expected.
It depends on how many protection layers you enable and the level you target. Plan for roughly 1.5x to 6x the runtime of plain JavaScript: light protection stays close to native, and the full anti-reverse-engineering and anti-LLM stack sits at the top of that range. Production mode strips debug output for smaller bundles and faster start-up.
So protect the logic that earns it, license checks, paywall logic, and proprietary rules, and keep tight inner loops out of the VM. That's where it pays off.
Both. The protected bundle runs in any modern browser or Node version, so you can apply it to server-side code too. Where it earns the most is the code that leaves your control: browser bundles, Electron and desktop apps, extensions, and anything you distribute to run on machines you don't own.
One CLI command produces a single self-contained JavaScript file, with no dependencies or build step for whoever runs it.
Yes. Thin-VM runs in production today, with performance tuning and stricter isolation modes for higher-risk work.
Protecting a paid SaaS, locking down your anti-fraud detection, or auditing what leaks from your front-end code? Tell us what you're shipping and we'll help you plan it.