How Does ?. Prevent Crashes?

It short-circuits the whole chain when it meets a null or a missing value. Instead of throwing, the expression evaluates to the empty value and the rest of the chain is never evaluated.

const response = { data: { user: { name: "Ada" } } };

console.log(response?.data?.user?.name);   // "Ada"
console.log(response?.missing?.user?.name); // undefined - no crash

const empty = {};
try {
  console.log(empty.data.user.name);
} catch (err) {
  console.log("crashed:", err.name);   // "TypeError"
}
console.log(empty?.data?.user?.name);   // undefined

The important detail is that the short-circuit happens at the first missing step and skips everything after it. If you wrote response?.data.user.name and the data property were missing, the chain would stop at the question mark and the later property accesses would not run, so no error would occur. The question mark therefore protects the whole expression to its right, not just the single property it sits next to.

Two related points. Optional chaining does not distinguish between null and a missing value; both stop the chain. And you can use it on a function call as well as on a property, so obj.method?.() calls the method only if it exists.

The one thing you cannot do is write an optional chain without an assignment or a call at the end of it. The language requires a chain to end in a reference, a call or an assignment, so you cannot write a bare obj?.prop as a statement. That restriction exists so that the operator cannot be used in a way that would silently swallow a genuine mistake.

They solve opposite halves of the same problem. Optional chaining stops a missing value from crashing the expression. Nullish coalescing supplies a fallback when the left side is null or missing. Together they let you read deep into data that might not be there and still end up with a sensible default.

const config = {
  retries: 0,
  timeout: null,
  name: "service",
};

console.log(config.retries ?? 3);      // 0 - zero is a real value
console.log(config.retries || 3);      // 3 - zero is falsy
console.log(config.timeout ?? 3000);   // 3000 - null triggers the fallback

// Chaining and coalescing together.
const settings = { nested: { theme: null } };
const theme = settings?.nested?.theme ?? "light";
console.log(theme);   // "light"

// Mixing ?? with || without parentheses is a syntax error.
try {
  eval("null ?? 0 || 3");
} catch (err) {
  console.log("mixed:", err.name);   // "SyntaxError"
}

That last part catches people. The language forbids combining the nullish coalescing operator with the double-bar or the double-ampersand operators in the same expression unless you add parentheses, because the precedence would otherwise be ambiguous and the result would be a footgun. The parentheses force you to state which fallback rule you meant.

The pairing is also where a subtle bug hides. If you use optional chaining with the double-bar fallback, you lose zero and the empty string. Writing config?.retries || 3 turns a legitimate zero into three. The nullish version keeps it.

One last distinction worth making. Optional chaining only guards against null and missing values. If a property holds the number zero, an empty string or false, the chain continues normally, which is correct behaviour, but it means you still need to validate those cases separately.

Reach for it when the shape of the data is genuinely uncertain. API responses, deeply nested configuration, optional properties on a component, and anything that came from outside your control are the classic cases. There, optional chaining turns a crash into a value you can handle with a fallback.

// Uncertain data: optional chaining is the right tool.
const apiResponse = { user: { profile: { name: "Ada" } } };
console.log(apiResponse?.user?.profile?.name);   // "Ada"
console.log(apiResponse?.user?.settings?.theme);  // undefined - no crash

// Your own data: optional chaining hides a real bug.
const config = { retries: 3 };
console.log(config?.retrys);                   // undefined - the typo is silent
console.log(config?.retrys ?? "fallback");      // "fallback"

// Zero and the empty string survive the chain.
const flags = { count: 0, label: "" };
console.log(flags?.count ?? 99);     // 0
console.log(flags?.label ?? "none"); // ""

It is the wrong tool when the shape is known and guaranteed. If your own code always creates the object, then a missing property is a bug, and hiding it behind optional chaining turns a loud failure into a silent one. The middle block of the example shows the cost: a mistyped property name produces no error at all, and the program carries on with a missing value that will cause trouble much later.

There is also a performance note, though it is small. The optional chaining operator cannot be optimised as aggressively as a plain property access in older engines, so in a very hot loop the difference is measurable. It is not a reason to avoid it in normal code.

Two more cautions. Optional chaining does not protect you from a missing property on the left of the chain, only from null and missing values at the point where the question mark appears. And combining it with a double-bar fallback silently discards zero and the empty string, which is why the nullish operator is the better partner.

For an interview, the framing that lands well is this: optional chaining is a tool for reading uncertain data, not a tool for hiding bugs in data you own.