History API: Change URLs Without Page Reloads
The History API lets you manipulate browser session history, enabling single-page app (SPA) routing without full page reloads. It's used to create "virtual" pages by changing the URL and state.
Why it exists
Before modern web APIs, changing the URL in the browser bar always triggered a full page reload from the server. This made creating fast, stateful, single-page applications (SPAs) difficult, as any navigation would wipe the application's current state and force a slow server round-trip.
The mental model
Think of the browser's history as a stack of states, not just URLs. The History API lets you programmatically push new states onto this stack (creating a new history entry) or replace the current state without reloading the page. The browser's back and forward buttons then pop states from this stack, firing an event your app can listen to.
How it works
The global window.history object provides methods to interact with the session history. The two most important are history.pushState(stateObject, title, url) and history.replaceState(stateObject, title, url). These methods update the browser's address bar and session history without initiating a network request. The stateObject can be any serializable JavaScript object that you want to associate with the new history entry. When a user clicks the back or forward button, the browser fires a popstate event on the window object. Your application must listen for this event to receive the stateObject and render the corresponding view.
When to use it
Use the History API to build SPAs with meaningful, shareable URLs and a functioning back button. It is the core technology behind client-side routing libraries like React Router, Vue Router, and the Angular Router. It allows you to create the user experience of a multi-page site with the performance of a single-page application.
When not to use it
Avoid direct manipulation of the History API if a robust routing library already handles it for you. It's not available in Web Workers, so all history operations must occur on the main thread. For simple, static websites with distinct HTML pages, traditional server-side routing is less complex.
One canonical example
A user is on /dashboard. They click a link to view their profile. Instead of a full reload, the app calls history.pushState({ userId: 'abc' }, 'Profile', '/profile/abc'). The URL bar updates, but the page doesn't refresh. The app's JavaScript renders the profile component. If the user then clicks the browser's back button, a popstate event fires, and the app's event listener re-renders the dashboard view.
Interview question
How does the History API enable single-page applications to correctly respond when a user navigates with the browser's back or forward buttons?
- a.The browser automatically re-renders the DOM based on the stateObject associated with the previous history entry.
- b.The history.pushState() method stores a callback function that is executed when the user navigates back or forward.
- c.It performs a partial page reload, fetching only the necessary content for the previous state from the server.
- d.It triggers a popstate event on the window, allowing the application to retrieve the associated stateObject and update its view.Correct
Why? this is the answer
When a user clicks back or forward, the browser fires a popstate event, which the application must listen for to retrieve the stateObject and render the appropriate view. The browser does not automatically re-render the DOM; the application is responsible for updating the UI.
Just read this? Test yourself on what you have been reading.
Read the original → developer.mozilla.org
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Every open role lists the topics its interview covers, so you can prepare for the real thing rather than guessing.
See open roles