DEV Community: Sanu Ranjan

Understanding GitHub OAuth Login

Sanu Ranjan — Mon, 31 Aug 2026 12:10:18 +0000

Starting With Redirects

This is a beginner friendly post.

I am writing it because the GitHub OAuth login flow confused the hell out of me, and it took me a long time to work out why. The confusion was not about the code. The code is short, and you can copy it from anywhere.

What frustrated me was a much simpler question that no tutorial answered directly:

What request/response are being sent/received and who is sending and receiving them?

Every diagram I found showed arrows going back and forth between a browser, my backend, and GitHub. I assumed my backend was talking to GitHub the whole time. It is not. Most of the time it is the browser doing the talking, and my backend is just handing it addresses to go to.

And no, asking an AI did not shortcut it for me. It was frustrating and I had to dig a lot, because AI does not know what gaps we have in our knowledge and neither do we. The answers came back fluent and correct but I stayed just as confused as before.

So if you are a beginner, expect to dig. Even the most advanced model will hand you a tidy summary that reads like understanding but is not one, and it will keep doing that until you learn to ask a sharper questions.

Once that clicked, everything else fell into place. So we are going to go slowly, and we are going to start well before OAuth.

The knowledge gap (Prerequisites)

HTTP requests and responses. You should know that a response has a status code, a set of headers, and a body, and their purpose.
What is a redirect request?(covered in the blog)
Chrome DevTools, specifically the Network tab. You need to be able to open it, watch requests appear as you click around, click a single request, and read its Request Headers and Response Headers. You should also know where the "Preserve log" checkbox is, because without it the list wipes itself every time the page changes, and in this flow the page changes four times.
Writing requests using the fetch API.
Cookies, at least the basics. What are cookies, their basic working, what the Set-Cookie header in a response does, that the browser stores it and attaches it to later requests automatically, and roughly what HttpOnly means. The Application tab in DevTools is where you look at them.
What are cross site requests, and how the browser decides what counts as one and handles it.
Authentication and Authorization with JWT using Express.
And the code used

Part 1: What a redirect actually is

Before we touch OAuth, we need to be completely solid on one thing. Everything depends on it.

The normal case first

When our browser asks a server for a page, it gets back a response made of three parts: a status code, some headers, and a body.

HTTP/1.1 200 OK
Content-Type: text/html

<html><body>Hello</body></html>

The status is 200, which means "here is what you asked for". The body is HTML. The browser paints that HTML on screen. The URL bar shows the address we requested. Nothing surprising.

Now the redirect

A redirect is a response with a status code in the 300s, usually 302, and no body at all.

HTTP/1.1 302 Found
Location: https://github.com/login/oauth/authorize?client_id=abc123

That is the entire response. There is no HTML. There is nothing for the browser to paint.

What there is instead is a header called Location, and its value is an address.

Here is the part I had wrong

I assumed, for a long time, that the server sending this response then goes to that address itself. It does not. The server has finished the request response cycle with this response. It wrote a string into a header, set a status code, and closed the connection. It is done. It has no idea what happens next and it does not wait to find out.

The browser is the one that acts. It reads the Location value and sends a brand new GET request to that address, entirely on its own initiative.

Let us be precise about what "brand new request" means, because this is where the whole flow lives:

It is a separate request, with its own connection.
It gets its own row in the Network tab.
It carries whatever cookies belong to that new address.
It is indistinguishable from the user having typed that address into the URL bar by hand.
If that address also replies with a redirect, the browser does this entire dance again.
And the most important thing is that the browser sends the query parameters along when it requests that address.

Why you never see it happen

Because nothing was rendered. The 302 response had no body, so there was nothing to display, so the URL bar had no reason to update.

This is why a chain of two or three redirects looks like a single instant jump on screen. There were three separate requests. We just never saw the intermediate ones, because none of them produced a page.

The sentence to carry into the rest of this post: a redirect response from someone is telling the browser where to go next.

If you take nothing else from this article, take that.

Part 2: The goal, and the flow in one pass

Now that redirects make sense, let us look at what we are actually building.

The goal is to log a user into our app without our app ever seeing their GitHub password. They type that password on github.com and nowhere else. Our app never touches it, never sees it, so it cannot leak it.

Here is the whole flow before we go into any detail. Read it once to set a context, then we will take it apart piece by piece.

The user clicks a "Log in with GitHub" button, which sends the browser to a route on our own backend.
Our server responds with a redirect pointing at GitHub. The browser follows it.
The user logs in on github.com and approves our app.
GitHub responds with a redirect pointing back at our server. The browser follows that too. The address it points at carries a temporary code.
Our server takes that code and calls GitHub directly, server to server, trading it for an access token.
Our server uses that token to ask GitHub who this person is.
Our backend saves the user, signs its own JWT, sets it in an HttpOnly cookie, and redirects to the dashboard.
And now the user is logged in to our app.

Now count how many of those are our server talking to GitHub over the network.

Steps 5 and 6. That is it. Two requests.

Steps 1 through 4 are all browser navigations, exactly like the one we described in Part 1. Our backend and GitHub are just taking turns handing addresses along with query parameters to our browser through redirect requests.

Part 3: The button, and why it points at our own server

Our login button is an anchor tag:

<a href="http://localhost:5000/api/auth/github">Log in with GitHub</a>

That one line has two decisions baked into it, and I got both of them wrong at first. Let us take them one at a time.

Question one: why does it point at our own Express server?

The obvious thing to do is put GitHub's authorize URL straight into that href. And it would technically work. So why bounce off our own backend first?

The answer is a query parameter called state. We will explain why in Part 7. For now, all we need is that the state must be a fresh random value on every single login attempt, and it must be stored in an HttpOnly cookie.

Hold those two constraints next to the idea of hardcoding the URL in our href.

An href written into JSX is a fixed string. It is baked in when the app is built. Every user, on every attempt, from now until we redeploy, would send the exact same state. A value that never changes is not random, so it defeats the purpose.

"Fine," I thought, "I will generate it in the browser with JavaScript."

But frontend JavaScript cannot set an HttpOnly cookie. That is the entire purpose of the HttpOnly flag. It exists specifically to keep JavaScript away from the value. So we would have to store our state somewhere JavaScript can reach, like localStorage, which means any cross site scripting bug in our app can read it and the protection is gone again.

Let's look at what actually needs to happen:

Generate a random value.
Store it in an HttpOnly cookie.
Send the redirect response taking the user to GitHub's login/consent page.

Those three things have to happen together, in one response. Only a server can do all three. The browser can do the third one, but not the second.

That is why the first stop is our own route, and GitHub comes one step later.

Our client_id, scope and redirect_uri differ between development and production, and on the server they come from environment variables. Keeping the URL construction on the backend means our frontend knows nothing about GitHub at all. That matters a lot the day we add Google login next to it, because nothing in the frontend has to change.

Question two: as the href holds the backend, why an anchor tag and not a GET request using the `fetch` API?

Because our route is going to respond with a redirect, and we need the browser itself to act on it.

An anchor tag hands control to the browser, and the browser makes the GET request and handles the redirect response received. That is what makes the rest of the chain happen at all.

Part 4: What our login route does

Three things, in a single response.

app.get("/api/auth/github", (req, res) => {
  const state = crypto.randomBytes(32).toString("hex");

  res.cookie("oauth_state", state, {
    httpOnly: true,
    sameSite: "lax",
    maxAge: 10 * 60 * 1000,
    path: "/",
  });

  const params = new URLSearchParams({
    client_id: process.env.GITHUB_CLIENT_ID,
    redirect_uri: "http://localhost:5000/api/auth/github/callback",
    scope: "user:email",
    state,
  });

  res.redirect(`https://github.com/login/oauth/authorize?${params}`);
});

Read res.redirect() carefully, because the name invites the wrong mental model.

It is not a function that reaches out to GitHub. It does not open a connection. It does not wait for anything. All it does is set a 302 status and a Location header on our response, and end it. Whether anything happens after that is entirely the browser's business.

Two things to notice in the params.

client_id is public. It sits in a URL. That is fine and by design.

client_secret does not appear here at all. It never goes near the browser. We will use it exactly once, in Part 8, from our server.

Part 5: The user is on GitHub now

The browser follows the redirect and lands on github.com.

Before showing anything, GitHub checks two things. That our client_id exists, and that the redirect_uri we sent is an exact string match for the one registered in our OAuth app settings. Not a close match but exact. One trailing slash difference and we get an error page instead of a login screen.

Then the user types their password.

This happens on github.com, on a page GitHub served, over GitHub's own TLS connection. Our app has no visibility into any part of it. There is no way for us to read that password even if we wanted to, because it is never sent anywhere near us.

That is the entire security promise of OAuth, and it is worth pausing on. The reason this whole convoluted redirect dance exists is to get that one property.

After the password, GitHub shows the consent screen listing the scopes we asked for. The user approves.

Consent only appears the first time. GitHub records that this user authorized this app for these scopes. On every later login it skips the screen entirely and redirects straight back, which is why the second login feels fast.

It reappears in two cases. If we add a scope the user has not approved, or if the user revokes our app at github.com/settings/applications. That second one is worth doing once during development just to see the screen again.

Part 6: The "callback URL" is a misleading name

This was the single biggest source of my confusion, so I want to be blunt about it.

GitHub does not call our callback URL. It never opens a connection to our server. Not once, at any point in the entire flow.

What GitHub actually does is send another 302 back to the browser:

HTTP/1.1 302 Found
Location: http://localhost:5000/api/auth/github/callback?code=abc123&state=xyz789

And then it hangs up. Same as Part 1. It set a status, wrote a header, and finished.

The browser reads that Location value and sends a fresh GET request to our server, carrying the code in the query string. The browser is the middle man.

So "callback URL" is the address we want the browser sent back to with the code in the query string.

Part 7: The state check, and a SameSite trap

Our callback route runs. The first thing it does is compare the state in the query string against the oauth_state cookie, and then clear that cookie.

Why?

Here is the attack it prevents. Follow it slowly, because it is easy to misread which account is which.

An attacker goes to GitHub and authorizes our app using his own GitHub account. He gets back a valid code. It is a real code, correctly issued, and it points at his account.

He does not use it.

Instead, he gets our user to load this address, maybe through a link in an email or an image tag on a page:

http://ourapp.com/api/auth/github/callback?code=HIS_CODE

Our server sees a code, redeems it, and logs that user's browser into the attacker's account.

Wait, why would he use his own account?

This is the part that confused me, and it is worth stopping on, because the attack looks backwards at first.

He is not trying to break into the victim's GitHub. He cannot. The code he planted was issued for his account, so our server reads his email, his profile, his numeric id, and logs the browser into his user record. The victim's GitHub is never touched at any point, and the user has no clue because there was no consent screen.

What he gets is everything the victim does afterwards.

The victim clicks the link and our app looks completely normal. They are logged in, nothing errors, and almost nobody checks which account they are in. So they carry on and use the app. They write notes, upload files, save a delivery address, connect something at checkout. All of it gets written against the attacker's user record.

Then he logs into our app from his own machine, normally, with his own GitHub, and reads it.

So the value of this attack depends entirely on what our app stores. On a login only app that holds nothing, it is close to worthless. On anything where users create, upload or save things, it is a real problem. The account is a container, and he has quietly handed the victim one that he owns.

How `state` stops it

The state cookie shuts this down cleanly. The attacker cannot read or set an HttpOnly cookie in someone else's browser. So his forged request arrives with a state that does not match whatever is in the victim's cookie, and our server rejects it before ever touching the code.

The SameSite trap

This one is confusing as hell.

Our oauth_state cookie belongs to our own domain. So I expected it to be sent to our own server without question. That is not how SameSite works.

SameSite is not about who owns the cookie. It is about which page the navigation started on.

Look back at Part 6. That redirect originates on github.com. So from the browser's point of view this is a cross site navigation, even though the destination is ours and the cookie is ours.

With SameSite=Strict, the browser withholds the cookie. Our state check then fails on every single login, and the error message will not tell us why, because from our code's perspective the cookie simply is not there.

SameSite=Lax is the minimum that works, because Lax permits cookies on top level navigations like this one.

We want Lax on our own session JWT too, for two separate reasons. First, the page load after login is the tail end of a chain that started on github.com. Second, if a user clicks a link to our site from Gmail or WhatsApp, Strict would land them on our page logged out, which looks like a bug to them.

Part 8: Trading the code for a token

This is the first time in the entire flow that our server talks to GitHub over the network. No browser is involved. Nothing here is visible to the user.

const tokenRes = await fetch("https://github.com/login/oauth/access_token", {
  method: "POST",
  headers: {
    "Content-Type": "application/json",
    Accept: "application/json",
  },
  body: JSON.stringify({
    client_id: process.env.GITHUB_CLIENT_ID,
    client_secret: process.env.GITHUB_CLIENT_SECRET,
    code,
    redirect_uri: "http://localhost:5000/api/auth/github/callback",
  }),
});

Two things here will waste an hour if nobody warns you.

Send Accept: application/json. Without it, GitHub replies with a form encoded string that looks like access_token=gho_xxx&scope=&token_type=bearer. Your tokenRes.json() will throw, and the error will not point at the missing header.

A bad code returns HTTP 200. Not 400. Not 401. You get a 200 OK with an error object sitting in the body. So if (!tokenRes.ok) will happily let a failure through. You have to check whether access_token is actually present in the parsed response.

Why is it safe for the code to travel through the URL?

This bothered me for a while. In Part 6 that code sat in the URL in plain text. Which means it went into browser history.

It is fine, because the code is single use and short lived.

The moment we exchange it, GitHub marks it consumed. Send the same code again and we get an error. And it expires on its own in about ten minutes whether we use it or not.

So anyone who digs that string out is holding something that has either already been spent or is about to expire on its own. The reusable, valuable thing is the access token we just received, and that never leaves our server.

Part 9: Finding out who they are

Here is a thing that is easy to assume and wrong: the access token does not tell us who the user is.

It is a key, not an ID card. It is proof that we are allowed to ask questions about the user logging in.

const headers = {
  Authorization: `Bearer ${accessToken}`,
  "User-Agent": "your-app-name",
  Accept: "application/vnd.github+json",
};

That User-Agent header is not optional. GitHub's API returns 403 Forbidden without it, and the error message does not obviously point at the cause. Every GitHub API request needs it.

Now we make our second and last server to server call.

https://api.github.com/user gives us the profile: id, login, name, avatar_url.

But email will very often come back as null, which is not a bug. Most people keep their email private on GitHub, and that endpoint respects the setting.

So we call https://api.github.com/user/emails as well. That returns an array of every email on the account, and we want the one where both primary and verified are true.

The verified part is not optional either. If the primary email is not verified, we treat the account as unverified rather than trusting the address. Otherwise someone could add an email they do not own to their GitHub account, log into our app, and get matched to an existing user in our database who does own it.

Part 10: Saving them, and our own session

Now that we have our user details, we set our own JWT using them as the payload and issue that to the client after login.

The short version

If we remember one thing from all of this, it is this:

Almost every step in OAuth is a server writing an address into a Location header and hanging up, while the browser does the walking.

So here is the exercise that taught me more than every diagram I looked at. Open DevTools. Go to the Network tab. Tick "Preserve log" so the rows survive all the page changes. Clear the list. Then run a login.

Go through them one at a time and find out, who sent this request, our server or the browser.

P.S. I wrote this while learning it, which means there is a decent chance something here is wrong or oversimplified. If you know OAuth properly and spot a mistake, please comment. Corrections are welcomed as the post gets better for the next beginner who lands on it.

How ChatGPT Understands Your Questions?

Sanu Ranjan — Wed, 01 Jul 2026 18:28:45 +0000

"My cat cant read this"

Held my laptop up, my cat stared at the screen for two seconds, then walked off like I'd personally offended her. Zero understanding. Fair enough, she's a cat.

But here's the thing that actually gets interesting, I can't fully explain how I read either. I'm doing it right now, obviously, but no neuroscientist on the planet can fully explain how my brain turns these squiggles into "oh, a cat joke." That one's still unsolved.

ChatGPT though, we can actually try to understand, not every step of it start to finish but can have an over all idea, no mystery here. So let's go through it properly, follow one sentence on its entire journey, from raw text to a reply showing up on our screen.

You type this into ChatGPT:

"My cat cant read this"

...and it immediately starts judging you(pun intended)

So how did it know? Let's actually go underneath the chat window, because that's the whole point of this post, not what ChatGPT is, but what it's actually doing to your sentence in the half second before it replies.

Underneath, it's a model doing exactly one job, look at some text, guess what word comes next. That's genuinely it. There's no separate grammar checker bolted on, no dictionary it's flipping through. Catching your missing apostrophe, understanding what you meant, replying like a smug know it all, all of that comes out of "guess the next word," just done at a scale that's hard to picture. Let's watch it happen on your actual sentence.

Step 1: Chopping the sentence up (Tokenization)

Computers can't read English, not even a little. All they work with is numbers. So before anything else happens, your sentence gets cut into small pieces called tokens , and each piece gets a number.

My cat cant read this → [My] [cat] [can] [t] [read] [this]

"cant" gets split weird, into [can] and [t]. That's because "cant" isn't actually a real word, it's missing its apostrophe, so the tokenizer, which only knows the chunks it was trained on(its vocabulary), does its best and breaks it apart. Every token maps to a fixed number, and that mapping doesn't change based on our intended meaning.

Step 2: Vector Embeddings

A number alone tells you nothing. 47 doesn't mean anything about "cat". So each token's number gets swapped for something bigger, a long list of numbers called an embedding , which works like a personality profile for that word. Words with related meaning end up with similar looking profiles. "cat" and "dog" sit close together numerically. "cat" and "computer" don't.

These profiles aren't invented fresh for our sentence. They're premade. Learned once during training, and just sitting there in a giant table afterward we can visualize it as words positioned in 3d space such that the distance between words represent how closely they are related. When our sentence comes in, the model isn't building a personality for "cat" on the spot, it's pulling "cat"'s profile off the shelf, already fully formed from having seen the word a billion times before during training.

Step 3: Remembering the order (Positional Encoding)

Small problem, the next step processes every token at once, together, not one after another. Which is fast, but it also means word order gets lost by default. "My cat cant read this" and "this cant read my cat" would otherwise look the same to it.

So before that step, each token gets a small stamp added to its profile, basically marking "I was word 1," "I was word 3," and so on, so the order survives even though everything's being processed together.

Step 4: Where the actual understanding happens (Self Attention)

Quick reminder before this part, by now every token isn't a word anymore, it's the number profile from Step 2, already stamped with its position from Step 3. That stamp matters here because attention checks every token against every other token all at once, not in order, so without it, the model would have no way to tell "My cat cant read this" apart from "this cant read my cat", same words, same profiles, totally different meaning.

When "cant" "looks at" every other word, it's doing a direct number comparison, checking how closely its numbers align with "cat"'s, "read"'s, and "My"'s. The closer the alignment, the more of that word's numbers get mixed into "cant". These alignments come from patterns the model picked up during training, but here's the honest part, we can't actually read those numbers and say "this is the grammar bit" or "this is the meaning bit." Nobody can point at them and narrate what each one means in plain English. What we can say is what happens mechanically, closely aligned words get blended in heavily, weakly aligned ones barely at all, and this runs for every token at once, all comparing against each other simultaneously. That's also why it doesn't lose track in long sentences, word 2 and word 200 can compare directly in one step, instead of that information passing hand to hand through every word in between.

Step 5: A private pass (Feed Forward Layer)

After the mixing in Step 4, each token's profile is just a blend of other tokens' numbers. This step takes that blend and reworks it through another formula, also learned during training, using only what this one token already has, no borrowing from others this time. As for what this reworking actually captures, same honest answer as before, we can't point at it and say in plain words what it's doing. What we can say is the shape of it, Steps 4 and 5 together repeat many times, stacked on top of each other, and across all those rounds each token's profile gradually shifts from a generic word into a word shaped by this specific sentence. The exact thing each round contributes isn't something anyone can narrate, but the end result is that every token's numbers end up reflecting the whole sentence around it, not just the word on its own.

Step 6: Actually picking a word (Softmax)

After all those rounds of Steps 4 and 5, the model has one final set of numbers for the position where the next word should go. Now it has to turn that into an actual word. It compares those numbers against every word in its vocabulary, tens of thousands of them, and produces a raw score for each one, how well each word fits given everything so far. Those raw scores are messy and hard to work with, some could even be negative, so they get run through softmax, which just squashes them all into clean percentages that add up to 100%. Something like "You" at 38%, "That" at 20%, "Well" at 9%, and so on down the list.

Then it picks a word from that list, usually leaning toward the higher percentages, adds it to the sentence, and runs the entire thing again from the start, tokenizing, embedding, comparing, reworking, all of it, to figure out the next word after that. One word at a time, which is why you watch the reply type itself out instead of appearing all at once. It's not being revealed to you from somewhere, it's being built, live, one word at a time, right in front of you.

Quick recap since this is the part that trips people up, the token list, the embedding profiles, and all the internal formulas are fixed. Learned once during training, frozen after that. None of it changes while you are chatting, no matter what you type. And to answer the obvious question, no, the model isn't learning from your conversation as you go. Your chats may still be collected and used to help train future versions, depending on the service and your settings, but even then that training happens later, offline, not while you type. It does improve over time, but only when the company trains and releases a newer version, and the version you're talking to right now stays exactly the same its whole life until it's swapped for a new one. What's fresh every single time is the computation itself, your specific words getting run through those frozen numbers in a way that's never happened before, because your exact may sentence have never existed before either.

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.