Client-side routing gets a long-overdue overhaul

For more than a decade, building single-page applications has meant working around the window.history API—a tool never designed for the job. Developers have had to manually connect that API to link clicks, DOM updates, and back/forward button handling to approximate standard multi-page behavior. The popstate event, which was supposed to help, has proven inconsistent: it doesn't fire for programmatic pushState() or replaceState() calls, and the API offers no way to read the full history stack or edit entries that aren't the current one.

That workaround era is ending. As of early 2026, the Navigation API has landed in all major browsers and is now Baseline Newly Available.

One event for every navigation

The old approach to client-side routing required assembling several separate pieces. You had to listen globally for clicks on <a> tags, call preventDefault() on them, manually invoke history.pushState(), update the DOM yourself, and then separately listen for popstate to handle back and forward buttons. Miss one edge case and users could end up on the wrong view.

With the Navigation API, all of that collapses into a single NavigateEvent that fires for every type of navigation: link clicks, form submissions, back/forward button presses, or your own code calling navigation.navigate().

The event.intercept() method carries most of the weight:

  • URL and history handled automatically: No more manual pushState() calls to update the address bar or history stack.
  • Accessibility built in: Focus management, including restoring focus after navigation, is handled automatically.
  • Centralized logic: The same function handles back button events and link clicks—no separate code paths.

Beyond basic routing

The Navigation API also solves problems that were awkward or impossible to address cleanly before.

Form submissions without reloads

The navigate event automatically intercepts all same-document form submissions, exposing the submitted data via the NavigateEvent.formData property. This allows you to capture a standard HTML form submission, prevent the page reload, and process the data asynchronously.

Control over scroll restoration

event.scroll() gives you explicit control over when the browser restores the scroll position during a navigation. By default, the browser attempts to restore scroll as soon as event.intercept() is called. That's a problem for modern SPAs where content often isn't rendered yet—you may be waiting on an API response. If the browser scrolls before the content exists, it lands in the wrong place or stays at the top.

Consider a user clicking the back button to return to a long list of items. The items must be fetched before the page is even long enough to scroll to the correct position. With event.scroll(), you can defer scroll restoration until after the data loads and the view is rendered.

App-like view transitions

The Navigation API and the View Transitions API are designed to work together. While intercepting a navigation event, you can wrap DOM updates in a document.startViewTransition() call. The browser captures a snapshot of the old state, performs the DOM changes, and then animates to the new state—enabling seamless, app-style transitions between views.

A router built for the modern web

The Navigation API resolves deep architectural issues that have plagued SPA development for years. It's built into the platform, handles edge cases robustly, and removes the need for the fragile glue code that the History API required. With support now available across all major browsers as of early 2026, it's ready for production use.