Most developers first encounter hoisting as a quick rule of thumb — "variables and functions move to the top." It sounds simple, even useful. But this explanation skips what is actually happening inside the JavaScript engine, and that gap leads to bugs, confusion, and a false sense of understanding. Hoisting is not a shortcut feature. It is a fundamental part of how JavaScript prepares your code before a single line executes.
Hoisting is the process by which the JavaScript engine allocates memory for declarations before execution begins. Nothing in your source code moves. The text you write stays exactly as it is. What changes is the internal state of the engine — it has already registered your identifiers, prepared their memory slots, and built the structure of your scopes before your code runs.
The three words that matter most here are allocation, declarations, and before execution. Hoisting is not about running your code early. It is about preparing the environment in which your code will run. Think of it like a chef organizing the kitchen before service begins — ingredients are placed, stations are set up, and tools are within reach. The cooking has not started yet, but everything is ready.
Understanding this distinction changes how you reason about JavaScript entirely.
Every time JavaScript creates an execution context — whether for the global scope or a function call — it operates in two distinct phases.
The first is the creation phase, sometimes called the memory phase or initialization phase. During this phase, the engine scans your code structure, registers identifiers, creates memory bindings, and links lexical environments together. No business logic runs here. No values are computed. The engine is purely building a map.
The second is the execution phase, where assignments happen, expressions evaluate, and functions are called. This is what most people think of as "running code." Hoisting belongs entirely to the first phase, which is precisely why behavior that seems out of order is actually consistent and predictable once you understand the model.
These two phases are the key to unlocking nearly every hoisting-related mystery.
One of the most important distinctions in JavaScript is the difference between declaring something and giving it a value. Hoisting only concerns declarations. The engine treats existence, initialization, and assignment as three separate internal operations.
When you declare a variable, the engine registers its name in the environment during the creation phase. When and how that binding gets a usable value depends on what kind of declaration you used. This is why different keywords — var, let, const, and function — behave so differently from each other despite all being declarations.
This distinction is not a quirk. It is a deliberate part of the language's design.
Function declarations receive the most complete hoisting behavior. During the creation phase, the engine does not just note that the function exists — it fully initializes the function object and makes it callable immediately. This is why you can call a function above where it appears in your code and it works without error.
This design is intentional. Functions are central to recursion, modular code, and scope structure. The engine prioritizes making them available early so that complex call patterns can resolve correctly. It is a practical decision baked into the language's architecture.
This full initialization is unique to function declarations, and distinguishes them sharply from other declaration types.
Variables declared with var are hoisted in the sense that a binding is created during the creation phase, but they are initialized with a default placeholder value rather than their actual assigned value. This is why accessing a var variable before its assignment in the code gives you undefined rather than an error — the binding exists, but no meaningful value has been placed there yet.
Variables declared with let and const are also hoisted at the binding level, but they behave very differently. Their bindings are created during the creation phase but are intentionally left in an uninitialized state. Attempting to access them before their declaration in the execution phase throws a reference error.
This restricted zone between scope entry and initialization is known as the Temporal Dead Zone.
The Temporal Dead Zone, or TDZ, is the period between when a block-scoped binding is created and when it is actually initialized during execution. Inside this zone, the binding exists internally but is completely inaccessible. Touching it causes an error.
The TDZ is not a bug or a limitation. It was introduced deliberately to prevent a class of problems that existed in older JavaScript, where variables could be accidentally accessed in unsafe states. The engine enforces the idea that existence alone does not mean readiness. A binding must be properly initialized before you are allowed to use it.
This stricter behavior is why let and const are generally safer and more predictable than var.
Hoisting does not happen in isolation. Bindings are always hoisted into a specific scope — the global scope, a function scope, a block scope, or a module scope. The scope determines where a binding lives, how long it persists, and from where it can be accessed.
During the creation phase, lexical environments are linked together to form what is called the scope chain. Hoisting is the process that populates these environments with their bindings before execution begins. This means that by the time any code runs, the full chain of scopes and their identifiers is already assembled.
Closures, one of JavaScript's most powerful features, depend entirely on this pre-built chain of environments.
A closure is a function that retains access to variables from its outer scope even after that outer scope has finished executing. This is possible because hoisting ensures that the relevant bindings and environments were established before execution began. The inner function does not reach back in time — it holds a reference to a lexical environment that was already properly constructed.
Without hoisting, closures would be unreliable. The environments that closures depend on would not exist in a predictable state at the time the inner function needs them. Hoisting is the invisible foundation that makes this work every time.
This is also why understanding hoisting matters well beyond simple top-of-file behavior.
It is worth stepping back to note that modern JavaScript engines do not simply read your code line by line at runtime. They parse your code, generate an abstract syntax tree, compile it, optimize it, and generate bytecode before execution begins. Hoisting fits inside this compilation pipeline.
This is why JavaScript is often described as both a dynamic and a compiled language. The parsing step discovers your declarations and scope structure. The hoisting behavior uses that information to set up lexical environments. By the time any code runs, the engine already has a complete picture of the program's structure.
Classes also follow this pattern — their bindings are created during the creation phase, but their initialization is restricted, much like let and const, because class evaluation depends on ordering and inheritance resolution.
The most useful way to think about hoisting is not as code moving upward on a page. Instead, imagine the engine constructing a complete lexical map of your program before runtime begins. Every scope is defined. Every identifier is registered. Every environment is linked to its parent. Only then does execution start filling in values and running logic.
This model explains why function declarations are callable before they appear, why var gives undefined instead of an error, why let and const throw inside the TDZ, why closures reliably capture their environments, and why deeply nested functions can still resolve identifiers through the scope chain.
Hoisting is not a small edge case to memorize. It is one of the core architectural mechanisms that shapes how every piece of JavaScript code runs.