JavaScript Closures: How They Actually Work

Sanu Ranjan — Fri, 26 Jun 2026 21:13:35 +0000

A quick note before we start: this post is for beginners trying to understand how closures actually work. I have done my best as per my limited knowledge to explain what happens under the hood, so if I have gotten anything wrong, please correct me in the comments.

When I was first learning closures, I could recite the definition but still could not explain why they actually work. Information that goes past the definition and into the "why" and "How" is sometimes harder to find than expected. One of my dear friends finally explained it to me in a way that made it click, so I thought I should pass it on for any beginner going through the same thing.

The definition we have probably heard: an inner function remembers variables from its outer function, even after the outer function has finished running. That is correct, but it is only the surface. The real question is, what is so special here? Why does that memory survive at all? The answer lives in how the JavaScript engine handles memory behind the scenes.

Here is the example we will use the whole way through:

function counter(n = 0) {
  var count = n;

  function innerCounter() {
    count++;
    console.log(count);
  }

  return innerCounter;
}

var a = 2;

var myCounter1 = counter();
myCounter1(); // 1
myCounter1(); // 2

var myCounter2 = counter(a);
myCounter2(); // 3
myCounter1(); // 3

I'm using var here just to make the breakdown easier to visualize.

How the Engine Runs the Code

Contrary to the popular belief that JavaScript is just a simple, line-by-line interpreted language, the engine handles the code in distinct steps. There are two phases:

The Compilation Phase: the engine scans the code and registers all variable declarations and function definitions before anything runs. For each function, it creates a function object in memory, and the function's name points to that object.

The Execution Phase: the code finally runs, line by line.

Separately from these, there's garbage collection: the cleanup process that runs in the background. Normally, once a function finishes executing, its local execution scope is freed from memory so it doesn't waste space. With a closure, that cleanup gets blocked. The executed function's local execution scope persists, letting the inner function reach back up the scope chain and grab what it needs.

Quick recap of the example above: counter takes a parameter n (default 0), stores it in count, and returns an inner function innerCounter that increments and logs count. We create myCounter1 from counter() and myCounter2 from counter(a), and the outputs come out as 1, 2, 3, 3. Now let's see how.

Step 1: Mapping the Global Scope

Before a single line runs, JavaScript sets up the global scope in memory during compilation, registering the names a, myCounter1, and myCounter2.

When it hits the counter definition, it creates a function object for it in memory, and the name counter points to that object. Here's the secret sauce: every function gets a hidden internal property (often written [[Scope]]) that points back to the environment where it was born. For counter, that points to the global scope.

Step 2: Creating myCounter1

Now execution starts. It sets a = 2, then calls counter() with no argument.

Invoking the function spins up a brand new local execution context, which points back to wherever its function definition's [[Scope]] is pointing to. Inside this temporary space, a mini-compilation happens:

n defaults to 0.
count is registered and initialized to 0.
innerCounter function is defined and stored and innerCounter holds reference to its function definition, and its hidden [[Scope]] points right back to this local scope.

Finally, counter() returns innerCounter, which returns the reference of its function definition and we store it in myCounter1.

Normally the local execution scope of counter() would now be wiped by the garbage collector. But JavaScript has a golden rule: if an environment can still be reached from the global scope, it can't be garbage collected. Since myCounter1 points to the inner function's definition, and the inner function points back to this local scope counter(), a bridge remains. The memory survives.

Climbing the Scope Chain

Now we call myCounter1(). A fresh local execution scope is created for the function execution which points back to wherever its [[Scope]] is pointing to, here it points to counter()'s local execution scope which is still in memory.

Then in execution phase for this function it encounters count++.

First it checks its own local context for count. Nothing there. So it follows up its scope chain into the preserved parent memory the counter() execution context, finds count at 0, increments it to 1 in that parent scope, and logs 1, and then myCounter1() local execution context is garbage collected.

The second call myCounter1() repeats exactly: it looks locally, finds nothing, climbs the chain, finds count now at 1, increments it to 2, and logs 2.

We get updated value here all because counter()'s local execution scope is still not garbage collected.

Step 3: Total Isolation with myCounter2

What happens when we create myCounter2?

Because we invoke counter fresh, JavaScript generates a completely separate, second local execution context. Here n receives the value of a (which is 2), so count starts at 2.

Calling myCounter2() climbs its own scope chain, finds its own count at 2, increments it, and outputs 3.

To prove the two environments share nothing, look at the final myCounter1(). It ignores whatever myCounter2 did, goes right back to its original environment, finds its old value of 2, increments it to 3, and logs 3.

Final Thoughts

At the end of the day, that's all a closure is. The outer function's local execution scope escapes garbage collection because the inner function's definition, whose reference is present in the global scope, keeps a live, reachable path back to the outer function's local execution scope via [[Scope]]. That persistent connection is what keeps the data alive across separate instances.