Modern client-side routing: the Navigation API

Standardizing client-side routing through a brand new API which completely overhauls building single-page applications.

Published on Updated on

This API was known as the "App History API" during development, but has since been renamed to the "Navigation API".

Single-page applications, or SPAs, are defined by a core feature: dynamically rewriting their content as the user interacts with the site, instead of the default method of loading entirely new pages from the server.

While SPAs have been able to bring you this feature via the History API (or in limited cases, by adjusting the site's #hash part), it's a clunky API developed long-before SPAs were the norm—and the web is crying out for a completely new approach. The Navigation API is a proposed API that completely overhauls this space, rather than trying to simply patch History API's rough edges. (For example, Scroll Restoration patched the History API rather than trying to reinvent it.)

The Navigation API launched in Chrome 102. Check out a demo here.

This post describes the Navigation API at a high level. If you'd like to read the technical proposal, check out the Draft Report in the WICG repository.

Example Usage

To use the Navigation API, start by adding a "navigate" listener on the global navigation object. This event is fundamentally centralized: it will fire for all types of navigations, whether the user performed an action (such as clicking a link, submitting a form, or going back and forward) or when navigation is triggered programmatically (i.e., via your site's code). In most cases, it lets your code override the browser's default behavior for that action. For SPAs, that likely means keeping the user on the same page and loading or changing the site's content.

A NavigateEvent is passed to the "navigate" listener which contains information about the navigation, such as the destination URL, and allows you to respond to the navigation in one centralized place. A basic "navigate" listener on could look like this:

navigation.addEventListener('navigate', navigateEvent => {
switch (navigateEvent.destination.url) {
case '':
case '':

You can intercept the navigation in one of two ways:

  • Calling transitionWhile() (as described above) to handle the navigation.
  • Calling preventDefault(), which can cancel the navigation completely.

This example calls transitionWhile() on the event with a promise generated from async functions. By calling this method, the browser knows that your code will configure the next state of your site. This will create a transition object, navigation.transition, which other code can use to track the progress of the transition.

Both transitionWhile() and preventDefault() are usually allowed, but have cases where they're unable to be called. You can't handle navigations via transitionWhile() if the navigation is a cross-origin navigation, for example, if it's leaving your domain. And you can't cancel a navigation via preventDefault() if the user is pressing the Back or Forward buttons in their browser; you should not be able to trap your users on your site. (This is being discussed on GitHub.)

Even if you can't stop or intercept the navigation itself, the "navigate" event will still fire. It's informative, so your code could, for example, log an Analytics event to indicate that a user is leaving your site.

Why add another event to the platform?

A "navigate" event listener centralizes handling URL changes inside an SPA. This is a difficult proposition using older APIs. If you've ever written the routing for your own SPA using the History API, you might have added code like this:

function updatePage(event) {
event.preventDefault(); // we're handling this link
window.history.pushState(null, '',;
// TODO: set up page based on new URL
const links = [...document.querySelectorAll('a[href]')];
links.forEach(link => link.addEventListener('click', updatePage));

This is fine, but not exhaustive. Links might come and go on your page, and they're not the only way users can navigate through pages. E.g., they may submit a form or even use an image map. Your page might deal with these, but there's a long tail of possibilities which could just be simplified—something that the new Navigation API achieves.

Personally, the History API often feels like it could go some way to help with these possibilities. However, it really only has two surface areas: responding if the user presses Back or Forward in their browser, plus pushing and replacing URLs. It doesn't have an analogy to "navigate", except if you manually set up listeners for, e.g., click events, as demonstrated above.


When your code calls transitionWhile() from within its "navigate" listener, it informs the browser that it's now preparing the page for the new, updated state; and that the navigation may take some time. The Promise you pass to transitionWhile() tells the browser how long the navigation takes.

As such, this API introduces a semantic concept that the browser understands: an SPA navigation is currently occurring, over time, changing the document from a previous URL and state to a new one. This has a number of potential benefits, including accessibility: browsers can surface the beginning, end, or potential failure of a navigation. Chrome, for example, activates its native loading indicator, and allows the user to interact with the stop button. (This doesn't currently happen when the user navigates via the back/forward buttons, but that will be fixed soon.)

Transition Success and Failure

After the "navigate" event completes, the URL being navigated to will take effect. This happens immediately, even if you've called transitionWhile().


This means navigation.currentEntry, location.href, etc. will update immediately. This impacts things like relative URL resolution when fetching new data or loading new subresources.

Many web and native applications immediately update the page with some sort of placeholder for the incoming content. But if you don't also immediately update the page's content, it will be out of sync with your application's programmatic view of the current entry and URL, which can be tricky.

These issues are being discussed on GitHub.

When you pass a promise to transitionWhile(), one of two things will happen:

  • If that Promise fulfills (or you did not call transitionWhile()), the Navigation API will fire "navigatesuccess" with an Event.
  • If that Promise rejects, the API will fire "navigateerror" with an ErrorEvent.

These events allow your code to deal with success or failure in a centralized way. For example, you might deal with success by hiding a previously displayed progress indicator, like this:

navigation.addEventListener('navigatesuccess', event => {
loadingIndicator.hidden = true;

Or you might show an error message on failure (i.e., if the Promise passed to transitionWhile rejected):

navigation.addEventListener('navigateerror', event => {
loadingIndicator.hidden = true; // also hide indicator
showMessage(`Failed to load page: ${event.message}`);

The "navigateerror" event listener, which receives an ErrorEvent, is particularly handy as it's guaranteed to receive any errors from your code that's setting up a new page. You can simply await fetch() knowing that if the network is unavailable, the error will eventually be routed to "navigateerror".

Abort Signals

Since you're able to do asynchronous work while preparing a new page, it's possible that the transition your code is handling (to load a specific URL or state) might get preempted, or considered out-of-date. This might happen because the user just clicked on another link, or your code performs another navigation.

To deal with any of these possibilities, the event passed to the "navigate" listener contains a signal property, which is an AbortSignal. For more information see Abortable fetch. The short version is it basically provides an object that fires an event when you should stop your work. Notably, you can pass an AbortSignal to any calls you make to fetch(), which will cancel in-flight network requests if the navigation is preempted. This will both save the user's bandwidth, and reject the Promise returned by fetch(), preventing any following code from e.g., updating the DOM to show a now invalid page navigation.

For a concrete example, you might set up loading a page of cat memes with a fetch() call in your listener. By passing the signal to it, the fetch will be cancelled if the user decides to instead load a different page on your site before the fetch completes. Take a look:

navigation.addEventListener('navigate', navigateEvent => {
if (isCatsUrl(navigateEvent.destination.url)) {
const processNavigation = async () => {
const request = await fetch('/cat-memes.json', {
signal: navigateEvent.signal,
const json = await request.json();
// TODO: do something with cat memes json
} else {
// load some other page

navigation.currentEntry provides access to the current entry. This is an object which describes where the user is right now. This entry includes the current URL, metadata that can be used to identify this entry over time, and developer-provided state.

Even sites that do not explicitly use the Navigation API will have a "current entry", and the entry is even updated or replaced if you use the older methods in the History API, history.pushState() and history.replaceState(), respectively.

The metadata includes key, a unique string property of each entry which represents the current entry and its slot. This key remains the same even if the current entry's URL or state changes. It's still in the same slot. Conversely, if a user presses Back and then re-opens the same page, key will change as this new entry creates a new slot.

To a developer, "key" is useful because the Navigation API allows you to directly navigate the user to an entry with a matching key. You're able to hold onto it, even in the states of other entries, in order to easily jump between pages.

// On JS startup, get the key of the first loaded page
// so the user can always go back there.
const {key} = navigation.currentEntry;
backToHomeButton.onclick = () => navigation.traverseTo(key);

// Navigate away, but the button will always work.
await navigation.navigate('/another_url').finished;


The Navigation API surfaces a notion of "state", which is developer-provided information that is stored persistently on the current history entry, but which isn't directly visible to the user. This is extremely similar to, but improved from, history.state in the History API.

In the Navigation API, you can call the .getState() method of the current entry (or any entry) to return a copy of its state:


By default, this will be undefined. You can synchronously set the state for the current NavigationHistoryEntry by calling:

navigation.updateCurrentEntry({state: something});

You can also set the state when navigating programmatically with navigation.navigate() (this is described below).

In the Navigation API, the state returned from .getState() is a copy of the previously set state. If you modify it, the stored version won't also change. For example:

navigation.updateCurrentEntry({state: {count: 1}});

const state = navigation.currentEntry.getState();
state.count = 2;; // will still be one

Access All Entries

The "current entry" is not all, though. The API also provides a way to access the entire list of entries that a user has navigated through while using your site via its navigation.entries() call, which returns a snapshot array of entries. This could be used to, e.g., show a different UI based on how the user navigated to a certain page, or just to look back at the previous URLs or their states. This is impossible with the current History API.

You can also listen for a "dispose" event on individual NavigationHistoryEntrys, which is fired when the entry is no longer part of browser history. This can happen as part of general cleanup, but also happen when navigating. For example, if you traverse back 10 places, then navigate forwards, those 10 history entries will be disposed.


The "navigate" event fires for all types of navigation, as mentioned above. (There's actually a long appendix in the spec of all possible types.)

While for many sites the most common case will be when the user clicks a <a href="...">, there are two notable, more complex navigation types that are worth covering.

Programmatic Navigation

First is programmatic navigation, where navigation is caused by a method call inside your client-side code.

You can call navigation.navigate('/another_page') from anywhere in your code to cause a navigation. This will be handled by the centralized event listener registered on the "navigate" listener, and your centralized listener will be called synchronously.

This is intended as an improved aggregation of older methods like location.assign() and friends, plus the History API's methods pushState() and replaceState().

These older programmatic methods for changing the URL are all still supported with the Navigation API and now fire the "navigate" listener. That is, they're also handled centrally. Their signatures aren't modified in any way (i.e., they won't now return a Promise) by this new specification, and we imagine that in an older codebase, they'll be replaced by calls to .navigate() over time.

The navigation.navigate() method returns a object which contains two Promise instances in { committed, finished }. This allows the invoker can wait until either the transition is "committed" (the visible URL has changed and a new NavigationHistoryEntry is available) or "finished" (all promises passed to transitionWhile() are complete—or rejected, due to failure or being preempted by another navigation).

The navigate method also has an options object, where you can set:

  • state: the state for the new history entry, as available via the .getState() method on the NavigationHistoryEntry.
  • history: which can be set to "replace" to replace the current history entry.
  • info: an object to pass to the navigate event via

In particular, info could be useful to, for example, denote a particular animation that causes the next page to appear. (The alternative might be to set a global variable or include it as part of the #hash. Both options are a bit awkward.) Notably, this info won't be replayed if a user later causes navigation, e.g., via their Back and Forward buttons. In fact, it will always be undefined in those cases.

Demo of opening from left or right

navigation also has a number of other navigation methods, all which return an object containing { committed, finished }. I've already mentioned traverseTo() (which accepts a key that denotes a specific entry in the user's history) and navigate(). It also includes back(), forward() and reload(). These methods are all handled—just like navigate()—by the centralized "navigate" event listener.

Form Submissions

Secondly, HTML <form> submission via POST is a special type of navigation, and the Navigation API can intercept it. While it includes an additional payload, the navigation is still handled centrally by the "navigate" listener.

Form submission can be detected by looking for the formData property on the NavigateEvent. Here's an example that simply turns any form submission into one which stays on the current page via fetch():

navigation.addEventListener('navigate', navigateEvent => {
if (navigateEvent.formData && navigateEvent.canTransition) {
// User submitted a POST form to a same-domain URL
// (If canTransition is false, the event is just informative:
// you can't intercept this request, although you could
// likely still call .preventDefault() to stop it completely).

const submitToServer = async () => {
await fetch(navigateEvent.destination.url, {
method: 'POST',
body: navigateEvent.formData,
// You could navigate again with {history: 'replace'} to change the URL here,
// which might indicate "done"

What's missing?

Despite the centralized nature of the "navigate" event listener, the current Navigation API specification doesn't trigger "navigate" on a page's first load. And for sites which use Server Side Rendering (SSR) for all states, this might be fine—your server could return the correct initial state, which is the fastest way to get content to your users. But sites that leverage client-side code to create their pages may need to create an additional function to initialize their page.

Another intentional design choice of the Navigation API is that it operates only within a single frame—that is, the top-level page, or a single specific <iframe>. This has a number of interesting implications that are further documented in the spec, but in practice, will reduce developer confusion. The previous History API has a number of confusing edge cases, like support for frames, and the reimagined Navigation API handles these edge cases from the get-go.

In the near future, it's hoped that an unrelated change to the HTML spec could introduce "historyless" IFrames which do not participate in the browser's history. IFrames which change their URLs have classically confused both developers and users because these changes have no effect on the user's URL bar or overall page title. So, e.g., a user pressing Back or Forward in their browser might not see an immediately obvious effect.

Lastly, there's not yet consensus on programmatically modifying or rearranging the list of entries the user has navigated through. This is currently under discussion, but one option could be to allow only deletions: either historic entries or "all future entries". The latter would allow temporary state. E.g., as a developer, I could:

  • ask the user a question by navigating to new URL or state
  • allow the user to complete their work (or go Back)
  • remove a history entry on completion of a task

This could be perfect for temporary modals or interstitials: the new URL is something that a user can use the Back gesture to leave from, but they then cannot accidentally go Forward to open it again (because the entry has been removed). This is just not possible with the current History API.

Try the Navigation API

The Navigation API is available in Chrome 102 without flags. You can also try out a demo by Domenic Denicola.

While the classic History API appears straightforward, it's not very well-defined and has a large number of issues around corner cases and how it has been implemented differently across browsers. We hope you consider providing feedback on the new Navigation API.



Thanks to Thomas Steiner, Domenic Denicola and Nate Chapin for reviewing this post. Hero image from Unsplash, by Jeremy Zero.

Last updated: Improve article

We serve cookies on this site to analyze traffic, remember your preferences, and optimize your experience.