In JavaScript, what is the difference between null and undefined, and why does a default parameter value apply when an argument is undefined but not when it is null?

## Two primitives, two origins `undefined` and `null` are both primitive types with exactly one value each, and both mean "nothing here". The useful distinction is not philosophical, it is about **who produced the value**. `undefined` is the language's own answer when it has nothing to give: ```js let x; // declared, never assigned -> undefined function f(a) { return a; } f(); // omitted argument -> undefined ({}).missing; // property that was never set -> undefined function g() {} g(); // no return statement -> undefined ``` `null` never appears by itself. It appears because someone typed it, or because a library chose it as a signal. A few standard-library calls do: `String.prototype.match` returns `null` when the pattern does not match, and `Object.getPrototypeOf` returns `null` at the end of a prototype chain. The rule of thumb stands: **undefined happens to you, null is chosen**. A small syntactic asymmetry follows from history: `null` is a literal built into the grammar, while `undefined` is an ordinary identifier that resolves to a non-writable global property. You cannot write `null = 1`, but you *can* introduce a local binding named `undefined` in an inner scope and shadow it. ## The default-parameter rule A default initialiser is not "used when the argument is missing" — it is used when **the argument's value is `undefined`**. Those are not the same statement, and the difference is exactly what interviewers probe. ```js function greet(name = 'guest') { return `hi ${name}`; } greet(); // 'hi guest' — omitted greet(undefined); // 'hi guest' — explicitly undefined counts as missing greet(null); // 'hi null' — null is a value, so it is kept greet(''); // 'hi ' — empty string is a value too greet(0); // 'hi 0' ``` The reasoning is consistent with the origins above. `undefined` is what "nothing was supplied" *looks like* in this language, so it is the trigger. `null` is a decision the caller made, and silently overriding a caller's explicit decision would be surprising. Destructuring defaults use the same rule, in object and array patterns alike: ```js const { port = 8080 } = { port: null }; console.log(port); // null, not 8080 const [first = 'a'] = [undefined]; console.log(first); // 'a' ``` ## When the initialiser runs Default initialisers are evaluated **per call**, at call time, and only for the parameters that need them — they are not computed once when the function is defined. That means they can be arbitrary expressions, can call functions, and can refer to parameters declared to their left: ```js function connect(host, port = defaultPortFor(host)) { /* ... */ } ``` `defaultPortFor` runs only on calls that omit `port` (or pass `undefined`), and it sees the `host` for that particular call. ## Where this bites in real code The classic failure is data crossing a boundary that turns "absent" into `null`. Databases store `NULL`; many serialisation formats and APIs emit an explicit `null` for an empty field rather than omitting the key. That value arrives in your function, sails past every default you wrote, and your code goes on to call a method on `null` — which throws. The bug reads as "my defaults do not work", when in fact they worked exactly as specified. The fix is a normalisation decision, made once at the boundary rather than defensively at every call site: either map incoming `null` to `undefined` as data enters the system, or stop relying on parameter defaults for that field and handle the absent case explicitly inside the function. ## Which one should your own code produce? There is no universal right answer, and interviewers are usually listening for a *defended* position rather than a particular one. - **Prefer `undefined` everywhere.** Consistent with what the language itself produces, and parameter and destructuring defaults then work on your own data. - **Prefer `null` for deliberate emptiness.** Gives you a way to distinguish "the caller explicitly cleared this" from "the caller said nothing", which matters for partial-update APIs where clearing a field and leaving it alone are different operations. What is genuinely wrong is having no rule, so that a field is sometimes missing, sometimes `undefined` and sometimes `null`, and every consumer has to test for all three. ## How to say it in an interview "`undefined` is the absence the runtime produces; `null` is the absence a programmer writes. Defaults trigger on `undefined` only — omitted or explicitly passed — because `null` is a value the caller chose. That is why `null` from an API response walks straight past your defaults."