Browser and DOM APIs

The browser reads your option names and never saw your build

Every platform API takes its configuration as an object with names the specification fixed. credentials, capture, sameSite, publicKey - the browser looks those up by spelling, and an unrecognised key is not an error. It is ignored, and the default applies. That is the third failure shape, and this is the surface where it happens most.

Read the Failure Modes Try Online Obfuscator

The Pattern

Ignored, not rejected

Web platform APIs are specified to skip options they do not recognise, so a renamed key produces a call that succeeds with different behaviour.

Option bagsfetch, addEventListener, cookies, IndexedDB. Names fixed by specification.

Callback contractsCustom element lifecycle, worker message shapes, event handler properties.

Markup contractsdata-* attributes, form control names, ARIA - text in HTML, not names in code.

The Pattern

Three ways a browser name escapes your bundle

A member name is safe while it stays inside the protected build. These are the three exits, and all three are common.

Into the platform

An option object handed to fetch, addEventListener, indexedDB or navigator.credentials. The specification fixed those keys.

Into markup

A data- attribute, a form control name, a framework binding such as {{item.total}}. Text in HTML that renaming never sees.

Into another context

A postMessage payload, a worker message, a stored record, a cached response. Serialised data keyed by member names, read by code that was protected separately or not at all.

The Articles

Grouped by what reads the name

Each article names the party that writes each field, runs the correct build first, then compares the protected build against it. Where a result is reported, it was executed rather than inferred.

Requests, sockets and streams

Option objects passed straight to the network stack, plus two reminders that a wire protocol is published by the code that speaks it.

Storage, cookies and credentials

The category with a migration problem as well as a rename problem: data written by a previous release carries the old names, so renaming makes existing user data unreadable.

Workers, isolation and cross-context messaging

Two contexts that were protected separately do not agree about names, and a message payload is serialised data keyed by member names.

Markup, forms and the DOM contract

The names in this group live in HTML, not in JavaScript. Renaming rewrites code and leaves the markup alone, which is exactly how the two ends stop agreeing.

Policy, delivery and playback

Headers and policies assembled in JavaScript and then read by something else entirely - a browser, a CDN, a corporate proxy, a licence server.

Frequently Asked

Common questions about this surface

Does obfuscation break fetch or XMLHttpRequest?

Not on its own. It breaks if member renaming reaches the option object, because the browser reads keys such as credentials, mode and headers by spelling and silently ignores anything else - so the request is sent with defaults.

Will obfuscation break my service worker?

Only if the worker and the page are protected in separate runs, or if renaming reaches the message payload keys they exchange. Keep every file of one application in one project so the naming decisions agree.

Do data-* attributes survive obfuscation?

The attribute in your HTML does, because renaming rewrites JavaScript and not markup. That is the problem: the dataset read in code moves and the attribute does not, so the two stop matching.

Does obfuscation break Content Security Policy?

Obfuscated output runs under a strict CSP as long as you do not enable an option that generates eval. Building the policy object itself is the sharper risk, because a renamed directive key is serialised into the header and silently ignored.

Are web components safe to obfuscate?

They need the most reserved names of anything on this page: the browser calls lifecycle callbacks and reads observedAttributes by name without ever appearing as a caller in your code.

Does protection affect accessibility?

No, when the accessible name comes from markup. It does when an ARIA relationship is built in code from a property name that has moved, which is the same markup-versus-code split as data- attributes.

Start with the shapes, not the list

The browser is one of several places a name escapes. The other three surfaces, and the shapes they fail in, are one click away.

Six Failure Modes › Protect Members Build and Tooling Protect a React Bundle