JavaScript Closures Explained Simply

Let’s be honest.

Closures in JavaScript sound scary at first.
You’ve probably seen definitions like:

“A closure is a function that retains access to its lexical scope…”

And your brain immediately goes: Nope.

But here’s the truth — closures are not complicated. You’re already using them. You just don’t realize it yet.

So let’s break it down slowly, clearly, and in a way that actually sticks.

First — don’t scroll

Look at this code.

function outer() {
  let name = "Alex";

  return function inner() {
    console.log(name);
  };
}

const fn = outer();
fn();

What do you think the output is?

Don’t skip. Think.

Now imagine you bet money on your answer.

Output:

Alex

If that surprised you even a little… good. You’re in the right place.

Now here’s the real question

Why is name still available?

outer() is already done. Gone. Finished.

So why didn’t name disappear with it?

If your answer is:

“Because JavaScript is weird”

No. That’s just avoiding the truth.

Or worse — memorizing without understanding.

This is where closures hit you

A closure means:

A function remembers variables from where it was created — not where it runs.

Read that again.

Not where it runs.
Where it was created.

If that still feels abstract, don’t worry — I’m going to corner you with examples.

Still not convinced? Let’s push you

Real scenario: Login system

function createLogin(username, password) {
  return function (inputPassword) {
    if (inputPassword === password) {
      console.log(`Welcome ${username}`);
    } else {
      console.log("Wrong password");
    }
  };
}

const login = createLogin("Sam", "pass123");

login("pass123");
login("123");

Output:

Welcome Sam
Wrong password

Now answer this:

Where is password stored?

Not global
Not inside login
Not accessible anywhere

Yet it still works.

And no, it’s not “saved somewhere magically.”

That’s closure.

And if that didn’t click yet, don’t worry — I’m not done with you.

Let’s corner you a bit

Try this:

console.log(login.password);

Before you run it — predict it.

Output:

undefined

So…

You can’t access it
But the function can

Sounds like magic?

It’s not magic. It’s memory + scope working together.

Real-world situation: You click a button

Let’s say you’re tracking clicks.

function createClickTracker() {
  let count = 0;

  return function () {
    count++;
    console.log(`Clicked ${count} times`);
  };
}

const click = createClickTracker();

click();
click();
click();

Output:

Clicked 1 times
Clicked 2 times
Clicked 3 times

Now don’t just read.

Answer this:

Why is count not resetting to 0?

Pause. Actually think.

Because you’re not creating count again.
You’re reusing the same closed-over variable.

Let’s make it uncomfortable

What if I do this:

const click1 = createClickTracker();
const click2 = createClickTracker();

click1();
click1();

click2();

Before you scroll — predict it.

Output:

Clicked 1 times
Clicked 2 times
Clicked 1 times

Now think carefully.

If closures were “shared memory”… this wouldn’t happen.

Each function has its own private world.

Yes — like separate tabs in your browser.

Real app logic: Shopping cart

function createCart() {
  let items = [];

  return {
    add(item) {
      items.push(item);
      console.log(`${item} added`);
    },
    view() {
      console.log(items);
    }
  };
}

const cart = createCart();

cart.add("Laptop");
cart.add("Phone");
cart.view();

Output:

Laptop added
Phone added
["Laptop", "Phone"]

Now I dare you:

console.log(cart.items);

Before running it — what do you expect?

Output:

undefined

So let me ask you:

If you can’t access items, how is it still updating?

Because it lives inside a closure.

Not global. Not exposed. Not reachable.

Hidden — but alive.

Now let’s catch a bug (you’ve probably made this)

for (var i = 1; i <= 3; i++) {
  setTimeout(function () {
    console.log(`Order ${i}`);
  }, 1000);
}

What do you expect?

Be honest.

Order 1
Order 2
Order 3

What actually happens?

Order 4
Order 4
Order 4

Yeah. That bug.

Don’t say “I wouldn’t make that mistake.”
You either already have — or you will.

Fix it using closure

for (var i = 1; i <= 3; i++) {
  (function (order) {
    setTimeout(function () {
      console.log(`Order ${order}`);
    }, 1000);
  })(i);
}

Output:

Order 1
Order 2
Order 3

Each loop creates a new memory.

Same code pattern. Different outcome.

That’s the twist closures bring.

Or use modern JS (yes, this is easier)

for (let i = 1; i <= 3; i++) {
  setTimeout(function () {
    console.log(`Order ${i}`);
  }, 1000);
}

Same correct output.

Because let creates a new scope every time.

Different keyword. Completely different behavior.

Pause. Don’t scroll yet.

If I ask you now:

What is a closure?

Don’t repeat a definition.

Say it like a developer.

Say it like you actually understand it.

The version you should remember

A closure is when a function carries its data with it, even after the original function is gone.

Not stored globally.
Not recreated.
Carried.

Quick self-check (no cheating)

What will this print?

function createDiscount(discount) {
  return function (price) {
    return price - price * discount;
  };
}

const discount10 = createDiscount(0.1);

console.log(discount10(200));

Don’t rush. Think.

Output:

If you got that right, you’re not guessing anymore.

If you didn’t — good. That means you’re actually learning instead of memorizing.

Final reality check

Closures are not some “advanced topic.”

They are used in:

React hooks
Event listeners
API handlers
Timers
State management

So if you skip this…

You’re not skipping theory.
You’re skipping how JavaScript actually works.

One last push

Next time you see:

Function inside function
Returned function
Hidden variables
Values that “don’t reset”

Don’t ignore it.

Stop and ask:

“What is this function remembering?”

That question alone will level you up.

And now you actually understand closures — not just pretend to.