Why does minified JavaScript often contain `void 0` where the source said `undefined`, and what does the `void` operator actually do?
answer
- an operator, not a function
- the result is always the same value
- three characters cheaper
- identifier versus operator
- undefined is not a reserved word
basics
~20 sThe void operator evaluates its operand, discards the result, and always produces the value undefined. Minifiers emit void 0 because it is shorter than the nine-character identifier undefined and cannot be affected by a local binding that shadows that identifier.
solid answer
~40 s`void expr` evaluates `expr`, throws the result away, and yields `undefined` — always, regardless of what the operand was. `void 0` is therefore a guaranteed way to write the undefined value in six characters instead of nine, which is why minifiers substitute it wherever your source said `undefined`. There is a correctness angle too: `undefined` is not a keyword, it is an ordinary identifier that resolves to a non-writable global property, so an inner scope can declare its own binding named `undefined` and shadow it. `void 0` is an operator applied to a literal and cannot be intercepted that way. In code you write yourself, prefer `undefined` for readability — but recognise `void 0` instantly when reading bundled output or older library source.
go deeper
Recognise void 0 in minified output and read it as the value undefined. Know it is an operator applied to a literal, not a function call, and that you should write undefined in your own source.
Explain both motivations: three fewer characters, and immunity to a local binding shadowing the undefined identifier. Be able to say that the operand is still evaluated and only its value is discarded.
Place it historically: before ES5 the global undefined was writable, so defensive library code needed a trustworthy source of the value. Explain why a tool rewriting arbitrary code still cannot assume the identifier is safe.
Treat this as a build-output-versus-source distinction. Source optimises for the reader, the bundler optimises for bytes, and your team's conventions and source-map tooling should keep engineers from ever needing to read the minified form to debug.
## What the operator does `void` is a unary operator. It evaluates its operand for its side effects, discards whatever the operand produced, and evaluates to `undefined`: ```js void 0; // undefined void 'anything'; // undefined void (2 + 2); // undefined let ran = false; void (ran = true); // undefined — but the assignment still happened console.log(ran); // true ``` The operand is not optional and it is not skipped: `void sideEffect()` really calls the function, then throws the return value away. ## Why minifiers rewrite undefined as void 0 **Size.** `undefined` is nine characters; `void 0` is six. Across a large bundle those three characters per occurrence add up, and the substitution is semantically safe in every context where a value is expected. **Safety.** `undefined` is not a reserved word. It is a property of the global object which, since ES5, is non-writable and non-configurable — so `undefined = 1` at global scope does nothing (and throws in strict mode). But because it is an ordinary identifier, an inner scope can still shadow it: ```js function weird(undefined) { return undefined; // whatever the caller passed, not the undefined value } weird(5); // 5 ``` A tool rewriting arbitrary third-party code cannot prove no such shadowing exists anywhere it operates. `void 0` sidesteps the question entirely: it is an operator applied to a numeric literal, and no binding can change what it produces. This is also why the idiom is much older than modern bundlers. Before ES5 made the global `undefined` non-writable, any script on the page could reassign it, and defensive library code used `void 0` — or an immediately-invoked function with an unfilled parameter — to obtain a trustworthy undefined value. ## Where else you will see void Old links written as `href="javascript:void(0)"` used it to produce a URL expression whose value was undefined, so that following the link would not replace the page with the expression's result. It is a historical idiom, not current practice, but it is the reason many people first met the operator. It also shows up occasionally as an explicit "I am deliberately discarding this value" marker in front of a call whose result is intentionally ignored. That usage is a style choice, not a requirement. ## What to do in your own code Write `undefined`. It is the clearer word, and on any modern baseline the global cannot be reassigned, so the defensive motivation is gone; disciplined code simply does not declare bindings named `undefined`. Let the minifier perform the substitution — that is a build-output concern, not a source-code one. The value of knowing this is diagnostic: when you open a stack trace, a source map that has not fully resolved, or a vendored bundle and see `void 0`, you should read it as "undefined" without pausing. ## How to say it in an interview "`void` evaluates its operand and always yields `undefined`. Minifiers use `void 0` because it is three characters shorter and, unlike the identifier `undefined`, cannot be shadowed by a local binding. I write `undefined` in source and expect the build to make that swap."
- Can you break code today by writing `undefined = 1` at the top of a script?No. Since ES5 the global `undefined` property is non-writable and non-configurable, so the assignment is silently ignored in sloppy mode and throws a TypeError in strict mode. What still works is shadowing — a parameter or a `let` binding named `undefined` inside a scope — which is why tooling that rewrites arbitrary code prefers `void 0`.
- Does `void someFunction()` prevent the function from running?No. The operand is fully evaluated first, including all its side effects; only the resulting value is discarded and replaced with `undefined`. If you want to skip the call you have to not write it — `void` is about the value of the expression, never about whether it executes.
- Is there any functional difference between returning `undefined` and returning `void 0` from a function?None. Both expressions evaluate to the same single undefined value, and callers cannot tell them apart. The choice is purely about readability and byte count, which is why it belongs to the build step rather than to your source.
saying these in an interview costs you the question
- Thinks void prevents its operand from executing
- Says void 0 returns null or the number zero
- Believes undefined is a reserved keyword like null
- Claims void 0 is faster rather than shorter and unshadowable
- Writes void 0 in source code for safety on a modern baseline