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 itself to them. It only takes effect together with vmSelfDefending: on its own it does nothing.

It is a small object. Today it carries a single field:

browserEnvironment: { transport: 'https' }

`transport`

The scheme your production serves the bundle over — 'http' or 'https'.

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.

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.

In the dashboard, the Transport control lives in the Advanced Protection panel and only becomes editable once VM Self Defending is on and the target supports it.

Requirements

Enabled together with vmSelfDefending; it has no effect otherwise.
A browser, browser-no-eval, or service-worker target.
Obfuscator version 7.9.0 or later.

Example

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

VM Domain Lock

How VM Transforms Code