Modern JavaScript

Protect the JavaScript your current build already produces.

TypeScript, JSX, framework templates, and modern modules should be compiled first. JavaScript Obfuscator then protects the generated JavaScript files before release, so your existing framework setup can stay exactly where it is.

Try Online Obfuscator Download Desktop App
Safe Pattern

Build first. Protect second. Test what you ship.

This keeps JavaScript Obfuscator out of your framework compiler and makes protection easier to review.

Framework safeProtect built JS instead of raw TypeScript, JSX, or single-file components.
Name safeKeep names stable when outside code depends on them.
Release friendlyProtect after bundling and before upload or deployment.
Two puzzle pieces fitting together to show JavaScript protection after the normal build is finished
Where protection drops in After your framework has emitted JavaScript, protection runs over the generated files. Your existing build tools keep doing the compilation work they already own.
Framework Fit

Use JavaScript Obfuscator after your project builds

The safest path is to protect the final JavaScript assets your project already produces. That keeps TypeScript, JSX, tree-shaking, minification, and code splitting in the tools that already handle them — and if you are weighing whether you need this at all, start with minification vs obfuscation.

React and JSX

Build JSX into JavaScript first, then protect the generated chunks. Exclude names called by external scripts or server-rendered markup. Full walkthrough: obfuscate a React bundle. On Next.js, mind the server/client split: protecting Next.js apps.

TypeScript

Run TypeScript compilation and type checking first. Protect the generated JavaScript, not the source files you edit. Guide: obfuscating TypeScript.

Vue and Angular

Let the framework compiler generate runtime bundles first, then apply protection to the emitted JavaScript files. Guides: Angular apps and Vue apps.

Svelte and SvelteKit

The compiler emits small imperative JavaScript with no framework runtime in the way — so the client chunk is almost entirely your logic. Keep authority in server modules, then protect the emitted client output. Guide: protecting Svelte apps.

Nuxt

Nitro compiles server/ into a bundle the browser never sees, while .output/public/_nuxt is downloaded by every visitor. Keep authority server-side, then protect the client chunks and reserve the payload keys. Guide: protecting Nuxt apps.

React Native

The Metro bundle ships inside the APK or IPA, and Hermes bytecode is decompilable with public tooling. Protect at the serializer stage, before Hermes compiles, and add runtime tamper signals. Guide: protecting React Native apps.

Node.js output

Protect server-distributed JavaScript when source visibility is a risk, then test startup, dynamic imports, and runtime configuration paths. Guides: Node.js source code, Electron apps and Tauri apps.

HTML5 games

Games ship gameplay and anti-cheat logic to every player. Build to the JS bundle first, protect cold paths hard and per-frame loops lightly, and keep the server authoritative. Guide: protect HTML5 / WebGL game JavaScript.

Embeddable widgets and SDKs

A script hosted by you and embedded by customers runs on pages you do not control, for the audience most motivated to copy it. Domain locking, watermarking and a deliberately reserved public surface do the work here. Guide: protecting a widget or JavaScript SDK.

Self-hosted and on-premises delivery

When the customer runs your application on their own hardware, the server stops being yours and may have no network at all. Per-customer builds, offline date locking and a signed release attestation replace the controls SaaS takes for granted. Guide: protecting a self-hosted or on-premises app.

Projects with no build step

Script tags, jQuery-era code and logic written directly into HTML, PHP or ASP pages never pass through a bundler, so the usual “protect the output directory” advice does not apply. The desktop app and mixed-file processing cover this case. Guide: protecting JavaScript without a build step.

Kiosks, signage and embedded devices

JavaScript shipped inside hardware has no hostname, an unreliable clock and often no network, and the domain, browser, OS and date guards all misread those conditions. Guide: protecting JavaScript on kiosks and embedded devices.

Online exams and assessment

An exam runs inside a browser the candidate administers, so no client-side check can make a score trustworthy. What is worth protecting is the scoring logic and adaptive routing, and two runtime-defense options collide with accessibility accommodations. Guide: protecting online exam and assessment JavaScript.

Web3 dApp frontends

The contract is public and the wallet holds the key, so the off-chain routing and risk logic is what protection is for.

Marketplace add-ins & plugins

Distribution through a reviewer you do not control, into a host runtime you do not own. Exclude the host API surface and pin the seed.

Low-code platform components

When the platform compiles your source and assigns the hostname, only uploaded artifacts can be protected at all.

ASP.NET, Razor and Blazor

Compilation protects the half of a .NET application that never left the server. What is still downloadable, where the Mixed Server Code option applies, and why a Blazor WebAssembly build needs a different tool for its assemblies.

E-learning and SCORM courseware

A course package runs on the customer’s own learning management system, so domain locking stops being a usable primary control and the LMS API names must survive renaming.

In-browser document viewers

Rendering requires the content, so delivery granularity sets the ceiling and the transform protects the viewer.

Browser extensions

Publishing to the Chrome Web Store? Obfuscation is prohibited there — minify, and keep secrets and proprietary logic server-side. Where obfuscation does apply, and where it doesn’t: protecting browser extension JavaScript.

Hybrid mobile (Cordova / Ionic / Capacitor)

The native wrapper isn’t protection — your JS ships readable inside the APK/IPA. Obfuscate the built bundle before packaging, keep secrets server-side, and know where JS obfuscation stops and native shielding begins: protecting Cordova / Ionic / Capacitor apps.

WordPress plugins

The wordpress.org directory forbids obfuscation and requires readable code — and your PHP moat is already server-side. What’s allowed, and where JS obfuscation applies (off-directory premium plugins): protecting WordPress plugin JavaScript.

Progressive web apps

An installed PWA copies your whole client onto the device and runs when your server is unreachable, so an offline check is made on hardware the user controls. Protect the service worker too, and put protection before the step that fingerprints your output: protecting a progressive web app.

Zero trust architectures

Zero trust removes location from the trust decision, which makes the browser the clearest case in the model: an artifact you published, running on hardware you do not control. That settles where each decision belongs and what a transform is actually contributing: zero trust and client-side JavaScript.

Recommended order
npm run test
npm run build
javascript-obfuscator-desktop-cli project.jso
npm run smoke:protected
deploy ./dist-protected
Keep Names Stable

Protect private logic while preserving names your app still needs.

  • Exclude global callbacks used by HTML attributes, analytics tags, or third-party widgets.
  • Preserve public method names that server templates, plugins, or external scripts call directly.
  • Use cross-file settings when multiple generated files must agree on shared renamed names.
  • Test protected output the same way you test any release candidate.
Proof Points

How modern JavaScript fits the protection workflow

Clear post-build guidance

Protection plugs in at the right spot for TypeScript, JSX, and framework-generated bundles — after compilation, before deployment.

Exclusion-first compatibility

The Variable Exclusion workflow preserves public names, callbacks, and framework integration points so protection never breaks the surface area you ship.

Team path

The integration guide gives release teams a repeatable pattern: build, protect, validate, deploy.

Frequently Asked

Questions this page gets asked

Where in a modern build pipeline should protection run?

After compilation and bundling, before deployment. Protection operates on the JavaScript you actually ship, so it belongs at the end of the build rather than on source files. Running it on TypeScript, JSX or framework source means fighting the compiler for no benefit, and it breaks the tooling that expects to read those files. The practical rule is to protect the contents of your output directory as the last step before publishing.

Does obfuscation work with TypeScript, JSX and modern syntax?

Yes, because by the time protection runs those have already been compiled to JavaScript. TypeScript types are erased at compile time and JSX has become function calls, so what protection sees is ordinary output. Declaration files are a separate artifact and are not protected, which matters if you publish a package: your type definitions describe your API in full regardless of what happened to the implementation.

Will protection break my framework's runtime behaviour?

Not if the public surface is excluded, which is what the variable exclusion workflow exists for. Frameworks resolve things by name at runtime such as component props, injected services, template bindings and lifecycle hooks, and those names have to survive. Everything internal to your build can be renamed freely. Most breakage reports trace back to a missing exclusion rather than to a defective transform.

Should every bundle get the same protection strength?

No, and choosing one preset for everything is the most common way to overpay. Protection has a real runtime and size cost, so it belongs on the code that carries value: pricing logic, entitlement checks, proprietary algorithms. A marketing page or a static component library rarely justifies a maximum preset. Splitting by chunk or by package lets you spend the overhead where it does something.

How do I debug production errors once the code is protected?

Keep the protection report for every release and use symbolication to translate obfuscated stack traces back to real names. The report is the only thing that makes an obfuscated trace readable, and it only works against the exact build that produced it, so retention has to outlive the release. For a reproducible investigation you can also rebuild with formatted output to get readable protected code you can set breakpoints in, which is a diagnostic build and never a shipping one.

Does protection interfere with code splitting or caching?

Not structurally. Dynamic imports and chunk boundaries survive, and the bundler integrations run before content hashes are computed so filename hashing still describes the bytes served. The one thing to watch is polymorphic output: without a seed, every build produces different bytes and therefore different hashes, so unchanged chunks lose their cached filenames. Set a seed when long-term caching matters.