It is increasingly common for "rich" applications to break the back button. I've always held that this was bad form but perhaps that view is outdated?

Is it ever Ok to break the back button? And if so, what are the criteria?

Edit: To clarify I was more referring to applications where clicking the back button basically just sends you right back where you were. Effectively disabled but not in any way harmful to press.

  • 4
    The "back" button is the single-best understood navigation function of a web browser. You break it at your peril. Check out what usability guru Jakob Nielsen says about it.
    – user1100
    Commented Aug 10, 2010 at 19:43

9 Answers 9


Only break the back button if it is expected (if it makes sense to not go back after an event in your website).

Mozilla did a study about how people are using its browser and the results for the back button are impressive:

The Back button is used far more often than any other navigation element (by which we mean the Back, Forward, Reload, Stop, and Home buttons). 93.1% of study participants used the Back button at least once, and on average, each user clicked Back 66.2 times over the 5 days – that’s 3x more clicks than the Reload button, 10x more than the Home button, and over 30x more than the Forward and Stop buttons!


I use the back button a lot and I hate it when I can't use it.

  • +1, taking away my back button is almost as annoying as taking away my save button.
    – Tim Post
    Commented Aug 10, 2010 at 16:47
  • Do you have a source for those statistics? I'd love to quote it to others...
    – Damovisa
    Commented Aug 11, 2010 at 3:36
  • @Damovisa sorry, I was sure I had put a link to the study (see bottom of quote for the link)
    – GoodEnough
    Commented Aug 11, 2010 at 5:37
  • This matches with my gut feeling, but when would users "expect" the back button to be broken.
    – Kris
    Commented Aug 11, 2010 at 9:19
  • @Kris whenever an action occurs that clearly changes the data in the previous page. After editing an entry for example in a form, after sending an email in Gmail, I don't expect to go back to the new email screen either. It doesn't happen very often though, if you're not sure, you should probably not break the back button.
    – GoodEnough
    Commented Aug 11, 2010 at 12:54

Breaking the back button is like breaking the brake pedal in a car. Users expect it to always work and when it suddenly doesn't mayhem ensues. The back button might be the most used UI feature in a browser so altering its behavior it any way can, at best, do no good, and, at worst, result in user confusion and abandonment (or increased customer support costs). Even if it takes the user right back to where they were that's not what they were expecting.

Breaking the back button should be avoided.


It is important to break the back button at sites where user is taking quiz, some banking sites. Generally , not a good idea.

  • Is it? Well, maybe banking sites and others that have irreversible actions.
    – Kris
    Commented Aug 11, 2010 at 9:30

Breaking the back button may be OK in some cases, but it is almost always unnecessary. I've seen it a lot with multi-step forms where you post from one page to the next to the next. What you should do in this instance is from your form page (1), post to a different page (2) that (for example) stores stuff in the session, then redirect back to another page (3). When the user presses the back button they will go from (3) back to (1).

Even with RIAs you can uses URL hashes/anchors (i.e. page.html#section) and monitor them for changes. Gmail does this for the different 'pages' like Inbox, Compose, Settings etc. This question on Stack Overflow will help if you if you want to implement that.


The main reason why it is "increasingly common" is that some RIA frameworks do not support the back button or require you to actively think about how to incorporate it's use into your application. Most frameworks do offer some support for navigation though, such as Silverlight 3's support for Frames and Page controls, you just have to know how to use it effectivly. The same navigation framework is used in Windows Phone 7 applications.


Studies have shown that almost 1/3 of clicks when using the browser is on the back button (from Don't Make Me Think). I honestly don't believe there is ever a good reason to stop the back button from working. people should be able to navigate around your site however they see fit.


My experience has been that unless you are using a contained framework such as an app WITHIN the context of a browser (like silverlight mentioned above), and have clear, suitable navigation in place, it is just not a good idea to start monkeying around with default functionality. In cases where I have seen it used there have almost always been problems with another browser being incompatible with the javascript or a session not always saving correctly, and when someone "accidentally" hits the button things tend to not continue on as expected.


I think I can sum up the responses as

You should never do that unless you absolutely can't avoid it. Even then you shouldn't.

Sounds about right.


Not to discount how "frequent" users press the back button, or that it simply isn't a "good idea" to "break" it, I would offer a different suggestion: The back button should take the user to somewhere before the user got to where they are now. In a lot of cases it makes more sense and is more usable to not take them one link-click back (and may be much easier to implement). For example, take browsing a photo album. The user make one click to select the album, is presented with thumbnails. Another click on a thumbnail shows that picture with next / previous links. At this point the user navigates through the album. When they're finished, they click back. At this point, it's more convenient and intuitive to go back to the thumbnail than to the previous picture.

In short, the back button should do something, but exactly what it should do depends on the application.

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.