Browser Environment

Section

Pro

v7.9.0+

Declare how your production build is served so the protected code can bind its integrity to it.

The browserEnvironment option declares facts about the environment your production build is served in, so the protected code can bind or react to them. It is a small object, and each field takes effect together with one specific protection — on its own the option does nothing:

browserEnvironment: { transport: 'https', hosting: 'remote' }

`transport`

The scheme your production serves the bundle over — 'http' or 'https'. Takes effect with vmSelfDefending.

With 'https', a copy a reverse engineer serves over plain HTTP will not run correctly. 'http' or an unset field adds no such protection.

A build declared transport: 'https' runs correctly only where it is actually served over https:. Every other scheme corrupts it, so declare it only when every context that loads your production build is HTTPS. That excludes:

plain http://, including http://localhost in development;
file:// — Electron, Cordova, and other packaged apps;
blob: and about: embeddings — a bundle running inside an about:blank or srcdoc iframe.

A client-side HTTP→HTTPS redirect still renders the HTTP page first, so the bundle must not run before the redirect completes.

`hosting`

Where your production bundle is served from — 'remote' or 'local'. Takes effect with vmDebugProtection, on the browser and browser-no-eval targets only. Requires obfuscator version 7.14.0 or later.

With 'remote', a copy a reverse engineer lifts and runs in their own local setup is treated as a runtime-environment mismatch, and the automation defenses react as configured by vmDefenseReaction. 'local' or an unset field adds no such protection.

A build declared hosting: 'remote' runs correctly only when it is loaded from a remote host. A bundle opened from a local setup — localhost, a dev server, file:// — is treated as a mismatch by design, so declare it only when every context that loads your production build is served remotely, and keep it off the builds you use for local development, testing, and CI.

Supported targets

browserEnvironment applies only to the browser, browser-no-eval, and service-worker targets. It is rejected for node, userscript, and bytenode — obfuscation fails with a validation error rather than silently dropping the setting. hosting is narrower still: it is accepted on a service worker but binds nothing there.

In the dashboard, the Transport and Hosting controls live in the Advanced Protection panel. Each becomes editable once the protection it pairs with is on — VM Self Defending for Transport, VM Debug Protection for Hosting — and the target supports it.

Requirements

transport takes effect with vmSelfDefending, hosting with vmDebugProtection; neither does anything otherwise.
A browser, browser-no-eval, or service-worker target (browser or browser-no-eval for hosting).
Obfuscator version 7.9.0 or later for transport, 7.14.0 or later for hosting.

Example

JavaScriptObfuscator.obfuscate(code, {
    vmObfuscation: true,
    vmSelfDefending: true,
    vmDebugProtection: true,
    target: 'browser',
    browserEnvironment: { transport: 'https', hosting: 'remote' }
});

VM Domain Lock

Using the NPM Package