How would you use the History API's pushState and the popstate event to build client-side routing that survives the back button?

Q: How would you use the History API's pushState and the popstate event to build client-side routing that survives the back button?

**Target Audience:** Engineers preparing for JavaScript fundamentals interviews. **Difficulty:** Medium > **How to read this doc:** Concepts are explained in plain language first, then tagged with 📌 Interview term: . Every claim below — including the exact restored state after a real back-button navigation — was verified live in a real browser, calling the same `history.back()` method the browser's own UI button triggers. ## 1. Why This Even Matters — A Story First A choose-your-own-adventure book that lets you flip back to an earlier page and pick up exactly where that page left off — remembering which chapter and which choice you had made there — only works if something is actually keeping a real bookmark at each decision point. `history.pushState()` plants that bookmark every time the URL changes; the `"popstate"` event is the moment the reader flips back and the book tells your app exactly which bookmark it landed on. ## 2. The Core Idea 📌 **Interview term:** `pu

Tricky JavaScript Scenario #91: History API route state handling

The problem

Question presented to candidate: "You're building a single-page app's router. You call history.pushState() to change the URL as the user navigates between views, with no full page reload. Now the user clicks the browser's back button — how does your app find out, and does it correctly restore the previous view?"

What a strong answer should cover:

📌 Interview term: history.pushState(state, title, url) — a real, built-in method that genuinely changes the browser's address bar URL and adds a real entry to the session history stack — with no page reload, no network request — while also storing an arbitrary state object associated with that specific history entry.
📌 Interview term: the real, direct answer to the prompt — verified directly, live: calling history.back() (the same real action the browser's own back button performs) genuinely fired a real "popstate" event on window, carrying the CORRECT restored state object from the entry being navigated back to, and location genuinely reverted to that entry's own URL — real, live proof that pushState-based routing genuinely survives the back button.
📌 Interview term: the real popstate listener responsibility — a precise answer names that the APPLICATION, not the browser, is responsible for actually re-rendering the correct view in response to popstate — the event only reports that navigation happened and hands back the stored state; a router must read event.state and update the UI accordingly itself.
📌 Interview term: pushState does NOT fire popstate — a precise answer names a real, easy-to-miss gotcha: calling pushState itself never triggers a popstate event — only actual back/forward navigation (via the browser UI, history.back(), history.forward(), or history.go()) does; a router's initial render logic must be triggered separately, not by assuming popstate will fire on the first pushState call.
A precise answer names history.replaceState() as the real sibling method — identical signature, but REPLACES the current history entry instead of adding a new one, useful for correcting a URL without creating an extra, unwanted back-button stop.

Clarifying questions expected:

None — this is a definitional/practical question; directly demonstrating the real, verified back-button-triggered popstate event with correctly restored state is the strong signal.

Code / implementation expected: Yes — real pushState calls building up history, a real history.back() call, and a real, observed popstate event with the correctly restored state.

routing
tricky
real-world

Try it yourself

Sketch your approach before you read the solution. That is what the interview tests.

Stuck? Get a hint.

A short nudge toward the approach. It will not give the answer away.

Solution

Target Audience: Engineers preparing for JavaScript fundamentals interviews. Difficulty: Medium

How to read this doc: Concepts are explained in plain language first, then tagged with 📌 Interview term:. Every claim below — including the exact restored state after a real back-button navigation — was verified live in a real browser, calling the same history.back() method the browser's own UI button triggers.

1. Why This Even Matters — A Story First

A choose-your-own-adventure book that lets you flip back to an earlier page and pick up exactly where that page left off — remembering which chapter and which choice you had made there — only works if something is actually keeping a real bookmark at each decision point. history.pushState() plants that bookmark every time the URL changes; the "popstate" event is the moment the reader flips back and the book tells your ap

The solution is hidden so you can try first

6 min read · 8 sections

Run the code

Edit the code and run it here. Each console line with an expected value becomes a test.

JavaScriptReal, live-verified proof: pushState builds up history with no reload, and a real history.back() call correctly fires popstate with the restored state — the exact prompt scenario