JavaScript Closures: The Complete Guide (with Cheat Sheet)

Open five browser tabs, click a button in each, and every single one logs 5. Not 1, 2, 3, 4, 5 — five identical 5s, as if the loop that created the buttons never ran at all. This is one of the oldest, most reliable JavaScript bugs there is, and it isn't a bug in JavaScript — it's a closure doing exactly what it's supposed to do, with a variable you didn't realize you were sharing.

By the end of this guide you'll be able to:

Who this is for: you're comfortable declaring functions and using var/let, and you've either been bitten by a callback that saw the "wrong" value or you've used useState in React and wondered why an old value showed up inside a useEffect.

Here's the naive way to wire up five buttons, each meant to log its own position:

Click any of the five buttons and the console prints You clicked button 6. Not 1, not the button's own number — always the same value, one past the last iteration. Nothing crashed, no error was thrown, and yet the code clearly doesn't do what it looks like it does. That gap between "what the code appears to say" and "what it actually does" is the entire reason closures deserve a real mental model instead of a shrug and a workaround.

The fix — spoiler, it's one keyword — comes in Stage 4. But the fix only makes sense once you know what a closure is actually holding onto, so that's where we start.

The mental model: a closure is a function bundled together with a live reference to the variables that were in scope where the function was defined — not the values those variables held at that moment, and not a copy. Every function you write in JavaScript carries this bundle with it, always; "closure" isn't a special kind of function, it's a name for a function's normal relationship to its surrounding scope.

Picture the function as a hiker who packs a backpack the moment they're created, and the backpack holds references to the variables visible around it — not photographs of their current values. If someone back at camp changes a variable in the backpack after the hiker leaves, the hiker's copy of that reference still points at the same variable, so they see the new value too. The hiker doesn't carry a snapshot from the moment they left; they carry a line back to the original.

makeGreeter finishes executing and its call frame would normally be discarded. But greet still references name, so the JavaScript engine keeps that specific name alive for as long as greet exists. That's the whole mechanism — every stage below is this one idea, applied to a slightly different problem.

The clearest way to see "reference, not copy" is to close over a variable and then change it after the closure was created:

This is also the answer to "why didn't count get garbage-collected when makeCounter returned?" It would have, if nothing still referenced it. Something does: the returned function. The variable's lifetime is now tied to the closure's lifetime, not to the block that declared it.

A plain object exposes its fields to anyone holding a reference to it — there's no way to stop account.balance = 1_000_000 from outside. A closure gives you a place to keep state that literally cannot be reached except through the functions you choose to expose:

There's no #balance private field syntax here, no WeakMap trick, no convention like a leading underscore that other code can ignore. balance simply isn't reachable from outside the three functions that closed over it — it never became a property of the returned object at all. This pattern (sometimes called the module pattern) predates JavaScript's class syntax and its #private fields, and it's still the right tool when you want a handful of functions to share hidden state without the ceremony of a class.

A closure is also just a convenient place to keep a cache between calls, with no global variable and no class:

▶️ Open the interactive playground →

Runs right in your browser — poke at it and watch the concept react live.

Back to the opening example. The bug is that var i creates exactly one binding for the entire loop — not one per iteration — because var is function-scoped (or global-scoped), not block-scoped. All five click handlers close over that same single i, and by the time anyone clicks a button, the loop has already finished and i is 6.

Fix 1 — use let instead of var. This is the fix that shipped in ES2015 specifically to solve this problem: let creates a fresh binding for i on every iteration, so each closure captures its own copy of the loop variable.

Fix 2 — wrap the body in an IIFE to force a new scope per iteration. This is the pre-ES2015 fix, and it's worth knowing because you'll still see it in older code: an immediately-invoked function expression creates a new function scope on every pass, and you pass the current i in as an argument, snapshotting its value at that instant.

Fix 3 — pass the value as a parameter to the handler factory. The same idea as Fix 2, expressed as a named helper instead of an inline IIFE — often the most readable option in real code:

All three fixes do the same thing: give each iteration its own variable to close over, instead of letting every closure share one. let just does it automatically, which is why it's the default choice today.

Reach for a closure when you want state shared by a small, fixed set of functions without exposing it (Stage 2), a cache or "computed once" value that should persist between calls (Stage 3), or a factory that produces several independent instances of the same behavior (Stage 1's makeCounter).

Avoid it when you have many methods that all need the same shared state — a class with private #fields expresses that more clearly and with less nesting than a pile of closures returned from one factory function. Closures and classes solve the same problem; classes read better once you're past three or four methods.

Watch it when the closure lives a long time — a global event listener, a setInterval that never clears, a cache with no eviction. The closure will keep everything it references alive for exactly that long, so audit what it's actually capturing, not just what you meant it to capture.

Because var creates one binding for the whole loop, and every closure created inside the loop shares that single binding — by the time any callback runs, the loop has finished and the variable holds its final value. See Stage 4 for three fixes.

No — it's a live reference to the variable itself, in the scope where it was declared. If that variable changes after the closure was created, the closure sees the new value, because it was never holding a snapshot in the first place.

They close over ordinary variables the same way. The difference is this: an arrow function has no this of its own, so it looks this up in its enclosing scope like any other closed-over variable, while a regular function's this depends on how it's called.

Yes, indirectly. A closure keeps its enclosing scope's variables reachable for as long as the closure itself is reachable. A closure attached to an event listener that's never removed, or stored in a cache that never evicts, holds onto whatever it captured for that entire time — that's a real, common source of leaks in long-running pages.

They're different concepts that usually overlap. A callback is a function passed to be called later by something else; a closure is the property that lets that function still see the variables from where it was defined. Almost every callback you write is also a closure — the two ideas describe different aspects of the same function.

Yes. An async function or a .then() callback closes over its surrounding scope exactly like a synchronous one — including the loop-variable bug, if you write var inside a loop that awaits or schedules something. let fixes it the same way.

Think it clicked? Take the 8-question quiz →

Instant feedback, a hint on every question, and an explanation for each answer — right or wrong.

Back to the five buttons from the top: swap that var for a let, and each one finally logs its own number — not because the bug fixed itself, but because each iteration now gets its own binding for a closure to hold onto. What's the first place in your own code you'd bet a var-in-a-loop closure bug is still hiding? Tell me in the comments.

🚀 Want more like this? Every guide, playground, and quiz lives on bestpractic.org — open it and sign up free so the next one finds you.

Thanks for reading! Let's stay connected: