BrowserRouter: Real URLs in React SPAs

Why it exists

Traditional websites serve a new HTML document for every URL. Single-page applications load one HTML page and update the DOM with JavaScript. Without a client-side router, the URL never changes, which breaks the back button, shareable links, and bookmarks. BrowserRouter exists to bring the navigation behavior of a multi-page website into a React SPA, letting the address bar reflect the current view while avoiding full page reloads.

The mental model

Think of BrowserRouter as a stage manager that swaps scenes based on the audience's ticket stub, which is the URL path. The audience can wave a new stub by clicking a link or pushing the back button, but the theater building never changes. The manager simply clears the stage and brings in the right actors for that path, all without the audience leaving their seat.

How it works

BrowserRouter wraps your application and listens to the browser's URL using the HTML5 History API. When a user clicks a Link component or calls navigate, the router intercepts the event and calls history.pushState to update the address bar. React Router then matches the new path against its route definitions and renders the corresponding component tree. Because the path is a real URL, a hard refresh or direct visit sends an HTTP request to the server for that path. The server must be configured to serve the same index.html for every route so the client-side router can take over.

When to use it

Use BrowserRouter when you are building a standalone React SPA and you want real, clean URLs like /dashboard or /users/42. It is the right choice when you control the hosting environment or when your platform supports catch-all routing. It also preserves standard browser behavior like forward and back navigation and allows search engines to crawl distinct URLs.

When not to use it

Do not use BrowserRouter if your server cannot be configured to handle dynamic paths and serve a fallback HTML file. In static hosting without rewrite rules, deep links will return 404 errors on refresh. In that situation, HashRouter is safer because the fragment after the hash is never sent to the server. Also avoid BrowserRouter inside Next.js apps that use the App Router or Pages Router, because Next.js manages its own routing and nesting BrowserRouter underneath will cause double routing, broken prefetching, and unexpected navigation behavior.

One canonical example

A React application built with Vite and deployed to Netlify. You wrap the app in BrowserRouter from react-router-dom, define routes for /login and /settings, and use the Link component for internal navigation. You then add a _redirects file with /* /index.html 200 so Netlify serves the SPA shell for every path. When a user copies /settings and opens it in a new tab, the server returns index.html, BrowserRouter mounts, reads the path, and renders the Settings page. Without that redirect, Netlify would return a 404.