On a traditional multipage site, the browser provides both routing and page history without the need for any extra effort. When a user visits a URL on the site, the browser asks the server for that URL's content, and then when the user moves to another URL, the browser tracks the change in the user's browsing history. In a Backbone-powered site, however, both of these must be handled by a Router instead. When the user visits a new page, the Router determines which Views to render, and when they leave that page, the Router informs the browser of the new history entry. This lets a Backbone-powered site act just like a traditional one, including allowing the user to use their browser's Back button.

There are two different approaches by which a Router can accomplish this, and Backbone lets you decide which approach you want to use. The first, and default, approach is hash-based routing, which takes advantage of URL fragments (also known as named anchors). You've probably seen URLs with these fragments before, for instance www.example.com/foo#bar. By using these fragments to define the pages of your site, Backbone can both know what page to load and can tell the browser how to track the user's movement across pages.

If you don't want your users to see hashes in your URLs, Backbone offers a second option that relies on the recently added HTML5 pushState technology. While this definitely helps URLs look cleaner, the pushState approach comes with a significant drawback. Although pushState is available in most web browsers, older browsers, such as Internet Explorer 9 and below, do not support it. If you try to use pushState-based routing in a browser without support for it, Backbone will instead fall back on hash-based routing. Even if only 1 percent of your users have an older browser, it still means that these 1 percent users will see a different URL from the rest of your users, which may cause confusion if (for instance) users with different browsers share links.

Routing based on pushState also has a minor drawback: if a user refreshes the page on a pushState-powered site, the browser will request that URL from the server. This can be solved by simply making your server return your application's single HTML page whenever the browser requests for such a URL. However, given both of these drawbacks, using pushState is only recommended if you care strongly about the appearance of your URLs and believe that all your users will have modern browsers.