Product Tour

How JavaScript Obfuscator protects public JavaScript.

Start online, move to the desktop app for larger projects, and use team options when protection needs to become repeatable. Along the way, JSO AI helps you pick presets, pre-check compatibility, and understand any error in plain English. This page is the quick product tour.

Try Online Obfuscator Download Desktop App Open documentation ›

The Engine

Protection levels that make JavaScript harder to read and copy

Each level removes information that makes public JavaScript easy to understand. Higher plans add stronger protection for code that matters more.

Hide readable names

Variables, parameters, and function names are replaced with short meaningless names, so the shipped file no longer explains itself.

All paid tiers

Hide searchable text

Important text is moved out of plain sight, making it harder to search the file for business rules, messages, or feature names.

All paid tiers

Protect important values

Maximum mode keeps important values harder to inspect directly in the protected file.

Maximum mode

Scramble program structure

The protected output no longer reads like the original logic, making the code harder to follow by hand or with automated tools.

Maximum mode

Change every release

Maximum mode changes the protected shape across releases, so repeat attackers and automated tools get less reusable structure.

Stronger protection

See It

Same function, before and after Maximum mode

A short license check on the left; a protected version on the right that is much harder to read at a glance.

Input

function validateLicense(plan) {
  if (plan === 'trial') return false;
  return plan.expiresAt > Date.now();
}

Maximum mode

(function(){var _0xa3=_dec(0x4a);
function _0xa4(_p){var _st=0;
 while(_st!==-1){switch(_st){
  case 0:if(_p===_dec(0x4b))return!1;
   _st=1;break;
  case 1:return _p[_dec(0x4c)]>
   Date[_dec(0x4d)]();
}}}})();

Real Product, Not A Demo

The desktop app, side by side with your project tree.

The WinUI desktop app protects plain ES5 .js offline in Local Standard mode. Paid Local Advanced keeps modern .js/.jsx and mixed HTML/server-script source with supported advanced transforms on-device after an online entitlement check, and writes the protection report locally. VM bytecode protection uses the service.

Whole-project batches, not single-file demos
JavaScript embedded in HTML, PHP, ASP, ASPX, JSP
Selected JavaScript uses the hosted protection service; surrounding mixed-file content stays local
Optional technical handoff for repeatable team releases

JavaScript Obfuscator desktop application showing batch project configuration and Maximum-mode preset

Desktop app on Windows · Maximum-mode preset shown

Where It Runs

Use it the way your team works

The same protection is available through a quick browser tool, a desktop app for bigger projects, and advanced options for release automation.

Online tool

Quick before-and-after preview for small samples. No install required.

Open the tool ›

Desktop app

Whole-project batches and mixed-file processing for larger jobs. Selected JavaScript is sent to the hosted protection service.

Download ›

Team integration

Advanced option for organizations that want protection connected to their existing release process.

Ways to use it ›

Editor and build tools

Optional tools for teams that want protection closer to their daily release workflow.

Integration options ›

Frequently Asked

Questions about trying it and shipping it

The things teams ask before they commit a protection step to a real release.

What can I try without installing anything?

The online tool gives you a before-and-after preview in the browser with no account and no install. It is deliberately scoped to samples rather than whole projects: uploads are capped at sixteen kilobytes and the protected sample it returns is capped at two kilobytes, and the endpoint is rate limited. Options that need extra values or that only make sense during desktop processing are skipped in the preview. It is the right way to see what the transforms do to code you recognise, and the wrong way to protect a real build.

What is the difference between the online tool and the desktop application?

Scale and workflow rather than a different engine. The desktop application handles whole-project batches, keeps a project file so a configuration is reused across releases, and processes mixed files where script sits inside markup. The online tool is a preview surface. Teams generally evaluate in the browser, then move to the desktop application or the command line package once they are protecting something real.

Do I have to send my source code to a server?

Not on every path, and this is worth being precise about because it is the question buyers ask most. There are workflows where the source body stays on the machine: a local mode in the Windows application and a local flag in the command line package. Those still perform an online entitlement check, so the machine needs connectivity, but the check carries no source. Virtual machine protection is the exception and remains a hosted step by design. The security and processing documentation states the boundary in detail.

How much does protection change my file size and speed?

It depends entirely on which transforms you enable, which is why the tour shows the levels separately rather than quoting a single number. Renaming alone is close to free and often smaller after minification. Control-flow flattening, string tables and virtualisation all trade size and startup time for reversal cost. The honest way to decide is to measure your own bundle at two or three settings on a representative device rather than accepting anybody's headline figure.

Which protection level should I start with?

Start lower than you expect to finish. Enable renaming and the string handling first, confirm your test suite passes against the protected artifact, then add heavier transforms one at a time so that if something breaks you know which option caused it. Jumping straight to the maximum setting on a large application is the most common way teams end up with a failure they cannot attribute.

Does the protected code still run everywhere my original did?

In the normal arrangement yes, because the engine preserves the language level it reads rather than transpiling. There is no ECMAScript target setting because no such transformation happens, and the runtime guards it injects are written in conservative syntax. Your browser support is decided by your transpiler configuration, and the way to confirm it is to run your existing tests against the protected build on the oldest configuration you support.

Can I automate this in a build pipeline?

Yes, and that is where most production use ends up. There is a command line runner and a package for Node-based builds with plugins for the common bundlers, so protection becomes a build step rather than a manual action somebody remembers to perform. The important sequencing rule is that everything which works by reading code, meaning linters, scanners, coverage and extraction tooling, runs before the protection step.

How do I debug a problem in a protected build?

By keeping the mapping information the build produces and symbolicating stack traces against it, rather than by reading the protected file. That is the same arrangement teams already use for minified production code, and it means a report from a user can still be turned into a location in your source. Rehearse it once before you need it, because discovering the workflow during an incident is expensive.

Ready to evaluate it on your real code?

Paste a function into the online tool to see what Maximum mode does to it. When you're ready for a project-wide test, the desktop app processes whole directories — including JavaScript embedded in HTML, PHP, ASP, ASPX, and JSP.

Try Online Obfuscator Download Desktop App Compare plans