I had a discussion with a friend about adding a custom back button on every page in a website.

What I mean by a custom back button is a link or a button, that will do just onclick="history.back();".

I think that this is useless and a bad practice, because there is already a built-in back button in the browser. Why should I add one to the page? User has to learn to use the browser.

My friend thinks that it is a good practice because it provides a better UI and a better UX to the user.

Is there any guideline about such things?

  • If the back button actually works in your app, then it may be a user preference question.
    – JeffO
    Mar 14, 2013 at 14:10
  • 1
    You should be able to get some useful information from previous questions about the browser back button that've been asked here over the past few years.
    – JonW
    Mar 14, 2013 at 14:40
  • 1
    If you are handling with sensitive data/forms etc.. Custom back button is good because user will not lose the data in the last page. If its just static pages, Browser back is enough Dec 19, 2013 at 12:31

6 Answers 6


I don't think there's any reason to have a back button that does the same thing as the browser's back button. (It's generally safe to assume by this point that your users know how to click back. Just make sure that your site functions in a way that the in-built browser back button will work.)

However, you may want to include an up button, as explained in Android's Design Guidelines. The back button built into Android functions similarly to the back button of a conventional browser, while the up button for each app instead goes to the next higher level of app/site hierarchy.

  • An 'up' link is just a slimmed down version of a breadcrumb really. At least a breadcrumb gives the user some feedback as to their current location within the website. An 'up' button is really only used on mobile devices due to space restrictions (well, it is in my experience anyway) because while it provides good functionality it doesn't offer the same level of feedback as a breadcrumb.
    – JonW
    Mar 14, 2013 at 14:52
  • @JonW I agree entirely. When I suggest using an up button, I mean that a good site should provide users with some way to navigate "backward" through site's hierarchy, independent of history. The best ways of doing this will, of course, provide the user with feedback about where they currently are within the hierarchy so that the behavior of the button/link can be anticipated. Mar 14, 2013 at 15:01
  • -1 for a general judgement. It is a detail depending on situation. There is no one for all answer. Dec 19, 2013 at 16:24
  • @DmitriZaitsev Can you provide an example of a situation in which the answer doesn't hold true? Dec 19, 2013 at 23:09

Generally a button which does the exact same thing as the browser's back button is unnecessary (make sure it works correctly though), but I can imagine some situations for which it could be useful.

  1. When your site focuses your user's attention primarily away from the browsers back button
  2. When using the browser in full-screen mode.
  3. For mobile browsing. (The android back button does not do exactly the same as the browser back button).

So you'll need to study how your users would use your app/website and base your decision onyour findings


Best practice is NOT to use a back button unless it is necessary.

If you are building a "wizard" (the user has entered a next/previous flow), a back/previous button could be desirable.

If the site architecture is very deep and has pages buried within pages that take several steps to navigate to, a "breadcrumb trail" may be more useful than a nondescript "back" button.

You have to ask your friend, what problem is the back button trying to solve?

In all usability studies that I have conducted and observed, users will overwhelmingly select the browser back button - even when an alternative back button is provided.


Historically, "Back" buttons were considered good usability because many browser-based applications did not have functional back buttons. In other words, the "Back" button would return the user to some unexpected location or it would throw an error. This led to heavy back button usage, and a lot of misconceptions about back buttons being good usability, when in reality they were a workaround.

In some older products, or products that do intensive db queries, this problem often lives on. For a shiny new product that is architected in such a way that the browser back button works, you should carefully evaluate the need for this extra button - and use it sparingly if at all.


"Back button" is a feature and as with any other application's feature, its usefulness will depend on many details like what is the application doing, who are the users, what other features are there etc.?

To have a constructive judgement, one needs to list all pros and contras, which I will attempt here.


  • Extra convenience. If placed and displayed right, an in-application Back Button can be more convenient to use. Browser's native buttons are often tiny. Even more important for people with disabilities.

  • Customization. An application disigner has the advantage to design a button optimized for the application. A more advanced application can even let users customize their buttons. Browser designer can only make it one-for-all solution.

  • Extra functionality. Here only sky is the limit. There is so many ways to make a custom Back Button behave better for user based on current application state, user's data, third party data etc etc.

  • Smooth in-application experience. It is always smoother to stay within application. Jumping to Browser's Back Button is fundamentally a switch to another interface breaking this smoothness.

  • Crystallising difference of purposes. The purpose of in-application Back Button is to go one step backwards in application. That is, I want to use it when I don't want to leave the application. In contrast, the in-browser Back Button is the one I use to get out of the application. Two very different purposes.

  • Reliability. Many applications actually break browser's Back Button behaviour. Then I rather rely on in-application one, where I expect the developers to do better job.

  • Lower cost. Yes, designing proper non-breaking behaviour for browser's Back Button can be costly. Think of the in-application routing. Libraries (like Backbone.js for example) have whole new components (Routers) just for that purpose. In contrast, with other buttons in place already, adding one more does not require major change.


  • Redundancy? Here it really depends on details. Maybe if your desktop is already cluttered with buttons, but then you may need to rethink your design in the first place. But if you only have very few buttons, would adding one more really hurt user experience?
  • +1 for a well-thought counterargument. I agree with most of the pros although (1) I wonder whether providing a non-standard method of navigation actually benefits disabled users and (2) if properly implemented with HTML5 history, I'm fairly certain that the point about reduced reliability is moot. Additional cons are (1) clutter, (2) wasted development time, and (3) confusion on the part of the user as to how the button will behave differently from the browser's back button. Dec 20, 2013 at 3:33
  • @3nafish Thanks. (1) There is only way to find out - ask those users. (2) The key is "properly implemented" :) At the end it all depends on details and what users say. Dec 20, 2013 at 4:42

Shouldn't your question be, "How to figure out what the user wants?" You may want to factor in what they're willing to pay you to build as well.

Don't predicate a feature request on the notion that the user just needs to be a better user/have more IT knowledge. Trust me, your competition will gladly cater to their needs. Some people decide what computer to buy based on what is easier to use which in their mind equals better.

We can debate this all day long and get nowhere. Ask the users, but keep in mind:

If you want to put in some custom code, this may be a good feature especially if your website is really an application. Some web apps explicitely tell users not to use the back button.

Is the next generation of browsers going to handle going back in history the same way? When your users upgrade and the back button no longer works, they're going to blame you. You'll try and blame their browser. Be prepared to lose that fight.

  • Thanks for your answer Jeff. It's not about webapps, it's about simple 'static' sites. Maybe it looks strange but I would like to see what developers think not the users. Mar 14, 2013 at 14:13

If the user is filling in a multi-page form, backward and forward buttons are useful.

If the built in browsers button don't work well (e.g. require resubmitting data) then you should redesign your site to make them work.

Additional back and forward buttons adjacent to your form may have multiple affects:

  • Enabling navigation between the steps of the form without moving attention from form

  • Showing the user that the back and forward functionality works in your site

  • The back and forward buttons can be limited to the scope of the form (e.g. no additional back button except on page 2+) and thus prevent accidental exit from form. This is particularly useful in mobile devices, where too many click on back to cause accidental close of tab/browser

  • Make sure these additional buttons do act the same as the browser's otherwise if the user does click on the browser's button, unexpected behavior may occur

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.