Our company is building an SPA and we're having a discussion about the best behavior for the browser back button. The SPA is a management tool with a lot of tables and filters. Every time a filter is changed the URL parameters are updated to reflect the current state.

There are two sides to the argument of what the back button should do:

  • One side thinks the back button should switch states. So every time a filter changes it should push the new state in the browser history.
  • The other side thinks the back button should switch pages. So filter changes should be ignored and the browser should return to the previous page/view.

Both options have their pro's and cons. Is there a common view on what the back button should do?

3 Answers 3


Test with your prospective users.

As you suggest, both sides have pros and cons but the best way to settle the matter is to get a bunch of users to test a prototype.

Taking control of the browser's back button can be very productive in situations where the user's view changes to the point where they feel like they are on a new page.

I would suggest performing the test from two different angles: 1) interview users while showing them the prototype and ask them if there are any situations when they might use the back button and what they expect to happen when they do. 2) build prototypes that work either way and see how users react when completing a task that implies the use of the back button.

You will probably find that the answer is a complex combination of both solutions depending on the context.

  • I agree with you about testing both options. Still I was wondering if there is any logical reasoning or common opinion about how the back button should behave for single page applications.
    – generator
    Aug 28, 2019 at 9:42
  • As I said in my answer, the problem with SPAs is that not every action or transition will feel to the user like a new page has been loaded. Without knowing your particular app, I couldn't possibly say what the behaviour of the back button should be at any given time. Aug 29, 2019 at 15:19


Provide your user with determinable action controls, that is, appropriate controls to remove filters that have been added and a navigation control to allow the user to go to the pages and locations they need to use your application.

Leave the browser back-button alone:

Breaking or Slowing Down the Back Button

The Back button is the lifeline of the web user and the second-most-used navigation feature (after following hypertext links). Users happily know that they can try anything on the web and always be saved by a click or two on Back to return them to familiar territory.

Except, of course, for those sites that break Back by committing one of these design sins:

•opening a new browser window (see mistake #2)

•using an immediate redirect: every time the user clicks Back, the browser returns to a page that bounces the user forward to the undesired location

•prevents caching such that the Back navigation requires a fresh trip to the server; all hypertext navigation should be sub-second and this goes double for backtracking

(source https://www.nngroup.com/articles/the-top-ten-web-design-mistakes-of-1999/)

  • 4
    That article is 20 years old and doesn't take into account how modern single page applications are built. The trick is to make the back button do what the user expects it to do and sometimes that involves taking control of it to return your SAP to an earlier state rather than taking it to the previous web page. Aug 27, 2019 at 15:01
  • 2
    Newer single page applications often give the user the sensation of moving through pages. If, for whatever reason, they decide they need to move backwards, their instinct would be to hit the back button. Taking control of the back button at that point would give the user exactly what they are expecting. On the other hand, if the back button is not under the control of the site, the user will be booted out of the application and back to square one of whatever task they are trying to achieve - Not very user friendly. Aug 27, 2019 at 15:07
  • 2
    They would know what they are expecting by testing their hypotheses with their target users. The back button is always going to have priority over any controls you add because (as you pointed out) it's cross-platform and cross-device; it's the one stable element in their navigation arsenal and you need to make sure it behaves the way they expect it to when they use it. Testing with users would tell the OP what to change in the next iteration to make the controls more user friendly. Aug 28, 2019 at 8:33
  • 3
    I agree with Andrew, there are actually very good reasons to 'mess' with the back button. The average users will not see the difference between navigating through pages in an SPA or a regular website. So it's our task as developers to make sure the back button behaves in the same way as any other regular website.
    – generator
    Aug 28, 2019 at 9:35
  • 2
    @DarrylGodden I keep saying the same thing because you don't seem to understand that users won't see a difference between page style transitions in a SPA and actual page transitions but will still use the back button to move through those transitions. I'm not sure what more logic you need to convince you that talking to users and finding out how to make products that behave the way they expect is what UX is about. Aug 29, 2019 at 15:15

It's true that tests are great...but in reality, many other things occur and one user using the back button might not be an argument. Also mobile-web contexts in which controls can be hidden & browser back is there always, or even under gesture can put another value to this discussion. I would suggest ensuring that at least visible steps work on the back button. Sometimes technology augmentation like SPA make us destroy reasonable approaches;)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.