Free lesson · JavaScript Basic to Advance

The Temporal Dead Zone

Easy5 min read

What Is the Temporal Dead Zone?

The Temporal Dead Zone — usually abbreviated TDZ — is the period between the start of a block and the line where a let or const variable is declared. During this period, the variable technically exists, but accessing it throws a ReferenceError.

// Temporal Dead Zone starts here for 'name'
//
// console.log(name);   // ❌ ReferenceError: Cannot access 'name' before initialization
// console.log(name);   // ❌ still in the TDZ
// console.log(name);   // ❌ still in the TDZ
//
let name = "Olena";   // TDZ ends here — 'name' is now initialized
//
console.log(name);    // ✅ "Olena"
console.log(name);    // ✅ "Olena"

The TDZ is the time before the variable's declaration line runs. The name is registered (we covered that in Topic 3.4 — hoisting), but reading from it isn't allowed yet. The moment execution reaches the let or const line, the TDZ ends and the variable becomes usable.

This is one of JavaScript's deliberate design choices, added in ES6, to prevent the silent undefined bugs that var allows. The TDZ makes "use before declare" errors loud and immediate instead of quiet and confusing.

Why the TDZ Was Designed

To understand the TDZ, you need to understand the problem it solves.

With var, reading a variable before its declaration gives you undefined. Your code doesn't crash. It might appear to work correctly. But if your logic was depending on the variable having a specific value, you've now got incorrect behavior with no visible signal that something went wrong.

function buggyVar() {
  if (count > 0) {   // count is undefined here, so this is "undefined > 0", which is false
    console.log("We have items");
  } else {
    console.log("Nothing here");
  }

  var count = 5;
}

buggyVar();   // Prints "Nothing here", even though count is clearly 5 later

The function prints the wrong branch because count was undefined when the if check happened. The var declaration was hoisted, but the assignment to 5 hadn't run yet. No error. Just silently wrong behavior.

The TC39 committee decided that this kind of silent failure was unacceptable for new keywords. So they designed let and const to throw an error in the equivalent situation:

function safeLet() {
  // if (count > 0) {   // ❌ ReferenceError — caught immediately
  //   console.log("We have items");
  // }

  let count = 5;
  console.log("count is", count);
}

safeLet();

The error stops your code immediately and points you at the exact problem. No silent bugs. This is the whole purpose of the TDZ.

When Does the TDZ Start?

The TDZ starts at the beginning of the enclosing block, not at the top of the function or file. Each let or const has its own TDZ, which exists from the start of its block to the line where the declaration appears.

function example() {
  // Outside any nested block

  if (true) {
    // TDZ for 'inner' starts here

    // console.log(inner);   // ❌ ReferenceError

    let inner = "value";    // TDZ ends here

    console.log(inner);     // ✅ "value"
  }

  // 'inner' doesn't exist out here at all
}

example();

The TDZ is bounded by the enclosing block. Inside the if block, there's a window between the opening { and the let declaration where reading inner throws an error.

This boundary is important to internalize. Some developers think the TDZ is about "the area before the line" — but it's specifically about the area within the same block, before the declaration. Outside the block, the variable doesn't exist at all (that's a different kind of error: it's not "before initialization" but simply "not defined").

graph TD
    A[Block begins with opening brace] --> B[Variable name is registered<br/>but not initialized]
    B --> C[Temporal Dead Zone:<br/>variable exists but is inaccessible]
    C --> D[Execution reaches the let/const line]
    D --> E[Variable is initialized with its value]
    E --> F[Variable is now usable]
    F --> G[Block ends — variable is destroyed]

    style C fill:#dc2626,color:#fff
    style F fill:#10b981,color:#fff

This diagram shows the lifecycle of a let or const variable within a block. When the block begins with its opening brace, the variable name is registered in the scope but not yet initialized. This creates the Temporal Dead Zone, where the variable technically exists but cannot be accessed. The TDZ ends when execution reaches the let or const declaration line, at which point the variable is initialized with its value and becomes usable. When the block ends, the variable is destroyed.

A Subtler TDZ Case: typeof

Here's a behavior that surprises everyone the first time. With var, you can use typeof on an undeclared variable without an error — it returns "undefined". With let or const in the TDZ, typeof throws:

console.log(typeof undeclaredVar);   // "undefined" — no error

// console.log(typeof letInTDZ);     // ❌ ReferenceError
let letInTDZ = "value";

The first line works because typeof is designed to be safe for checking the existence of variables. It returns "undefined" for variables that don't exist, instead of throwing.

But for let and const variables in their TDZ, typeof doesn't get this exemption. The variable exists in the scope (just in the uninitialized state), and accessing it in any way — including with typeof — throws the ReferenceError.

This is a real interview gotcha. Senior interviewers sometimes ask "what's the difference between typeof someVar for an undeclared variable versus for a let variable in the TDZ?" The answer demonstrates whether you understand the TDZ at the engine level or just at the surface level.

The TDZ in Loops

In Topic 3.3 we saw the classic for-loop bug — the one where var i shared across all iterations causes all timer callbacks to see the same value. The TDZ is part of why let fixes that bug.

for (let i = 0; i < 3; i++) {
  // Each iteration creates a NEW 'i' with its own TDZ
  // The TDZ at the start of each iteration is filled by the loop's initialization
  setTimeout(() => console.log(`i is ${i}`), 10);
}

Each iteration of the loop creates a fresh binding for i. The TDZ exists at the start of each iteration but is immediately filled by the loop's initialization expression. The captured i in the timer callback is the iteration-specific one, not a shared one. This is why let in loops works correctly while var doesn't.

Common Pitfalls

Warning: Three TDZ traps that show up in real code.

Using a variable above its declaration assuming it's undefined. Beginners coming from var habits sometimes write code that reads a variable above its declaration line, expecting undefined. With let or const, this throws. The fix is simple: move the declaration above the use, or refactor so you don't read variables before declaring them.

typeof checks in the TDZ. Using typeof is normally safe — it returns "undefined" for undeclared variables without throwing. But inside the TDZ of a let or const, typeof does throw. Don't rely on typeof to check whether a let variable has been initialized.

Default parameter references. If a function parameter's default value references another parameter that hasn't been initialized yet, you'll hit a TDZ error. For example, function f(a = b, b = 1) {} throws because b is in its TDZ when a's default is evaluated. Parameters are initialized left-to-right.

Why This Matters in Interviews

Interview: The TDZ shows up in interviews at the senior level, where interviewers want to test depth on hoisting and execution contexts. Common forms:

• "What is the Temporal Dead Zone?" — Answer in terms of the period between block start and declaration line, where the variable exists but is inaccessible. Mention that it's a deliberate design choice to prevent silent bugs.
• "What's the difference between typeof x for an undeclared x versus a let x in the TDZ?" — Undeclared returns "undefined". TDZ throws ReferenceError.
• Output prediction with let declarations in unusual positions to see if you catch the TDZ.

Topic 3.6 — Interview Lens: Variables, Scope, and Hoisting — covers the full interview-prep treatment, including how to talk through these mechanisms under pressure.

Try It

Exercise: Predict what each line does — runs successfully, prints something specific, or throws which kind of error.

// Block A
console.log(typeof noVarAtAll);

// Block B
console.log(typeof letInTDZ);
let letInTDZ = 1;

// Block C
console.log(varBeforeDeclaration);
var varBeforeDeclaration = 1;

// Block D
{
  const value = "inside";
}
console.log(value);

Each block tests a different aspect of hoisting or the TDZ. Identify what happens in each. Once you can predict all four without running them, you've mastered hoisting at a level most JavaScript developers never reach.

Back to JavaScript Basic to Advance