Language Features

The language survives. Names that are read as strings do not.

Q: Does obfuscation break closures or the value of this?

No. Both are structural: a closure is a scope chain and this is decided by the call form, and a transform that renames a binding renames every reference to it in the same pass. The measured articles find no behaviour change from protection alone.

An obfuscator is allowed to rename bindings, reorder declarations and rewrite control flow. It is not allowed to change what the program means. That distinction settles most of this list before you read it: structure is safe, and identity that happens to be a string is not. Function.name, a property key read by reflection, a named capture group and a registered symbol are all strings at runtime, and a string is exactly what a rename changes.

Read the Failure Modes Try Online Obfuscator

The Dividing Line

Two kinds of identity

Ask how the runtime finds the thing. If it follows a reference, a rename follows with it. If it looks the thing up by spelling, the rename is a different spelling.

StructuralScope, closures, prototypes, iteration protocol. Renamed consistently, so behaviour is preserved.

TextualFunction.name, reflected keys, capture group names, Symbol.for keys. The spelling is the value.

NeitherRegular expression bodies and string contents are not obfuscated by renaming at all.

The Rule

Structure is renamed consistently; spelling is not

Three questions settle almost every case on this page, and you can answer all three without running anything.

Who resolves it?

If your bundle resolves the name, the rename moves both ends together. If the runtime, a library or a stored record resolves it, only your end moves.

Is it a string at runtime?

obj.total is a reference the transform can follow. obj["total"] built from data, Object.keys, and Symbol.for("total") are not.

Does the target matter?

Lowering to ES5 rewrites destructuring, defaults, classes and iteration. Those rewrites are where a language question becomes an engineering one - see Output Target.

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.

Scope, binding and control flow

The structural core. A transform renames every binding and its every reference in one pass, so these hold by construction - the articles record where the edges are.

Objects, prototypes and reflection

Where member renaming actually lives. Anything that reaches a property by spelling - a reflected key, a serialised field, a capability probe - is reading the name rather than following a reference.

Iteration, async and templates

Protocols the runtime drives rather than your code. The engine calls a well-known method; the question is whether the rewrite preserves laziness and call-site identity.

Values, text and numbers

Downlevel targets are the interesting part here: lowering modern syntax for older engines is where a semantic difference can creep in, which is why each of these was executed on both targets.

What renaming never touches

Two reminders that renaming is not encryption. A regular expression body and a heap profile are both readable after a rename, because neither is a name.

Frequently Asked

Common questions about this surface

Does obfuscation break closures or the value of this?

No. Both are structural: a closure is a scope chain and this is decided by the call form, and a transform that renames a binding renames every reference to it in the same pass. The measured articles find no behaviour change from protection alone.

Does obfuscation change Function.name?

Yes, and that is unavoidable - the name of a function is the identifier, so renaming the identifier renames it. Any code that dispatches on fn.name, or logs it and matches on the result, needs those functions reserved.

Are my regular expressions protected?

No. A regular expression literal is data, not a name. Renaming leaves the pattern intact and readable, which matters when the pattern itself encodes a rule you would rather not publish.

Do private class fields survive?

They are already private to the class body, so a consistent rename keeps them working. The care is needed where a public getter exposes one under a name a template or an API response also uses.

Is ES5 output semantically identical to modern output?

Close, and the differences are the ones every downlevel compiler has: the temporal dead zone is lost and Function.prototype.length changes for defaulted parameters. Babel and TypeScript make the same trades.

Which of these need an exclusion rule?

Only the ones read by spelling: reflected keys, serialised field names, registered symbols, and any function whose name is used as data. Everything structural is safe without configuration.

Start with the shapes, not the list

The list above is a reference. The synthesis - what the failures look like and which direction they go - is on one page.

Six Failure Modes › Name Mangling Output Target Browser and DOM APIs