Restrict or Disable Browser Back Button Using JavaScript

← PrevNext →

Last updated: 30th June 2025

While disabling the browser back button in JavaScript can enhance data security and prevent unwanted navigation, it's generally not recommended for use in live websites. This technique, although effective for maintaining the integrity of online data, can lead to a frustrating user experience, especially for visitors who expect to return to the previous page.

restrict or disable browser back button

While restricting browser actions can frustrate users, developers may find it useful in controlled scenarios to maintain workflow integrity. For example, many online banks disable the refresh or back button to prevent data loss during critical transactions.

In this tutorial, we’ll demonstrate how to disable the back button using JavaScript across two simple HTML pages, ensuring the user cannot return to the first page once they proceed.

So, first create two HTML pages, page1.htm and page2.htm.

The first page (page1.htm)
<!DOCTYPE html>
<html>
<head>
  <title>Disable Browser Back Button Using JavaScript</title>
  <script src="https://ajax.googleapis.com/ajax/libs/jquery/1.9.1/jquery.min.js"></script>
</head>
<body>
  <a href="page2.htm" target="_blank">Click Here...</a>

  <script>
      $(document).ready(function () {
          function disableBack() {
              history.pushState(null, null, location.href);
              window.onpopstate = function () {
                  history.go(1);
              };
          }
          disableBack();
      });
  </script>
</body>
</html>

The history.pushState() and onpopstate() offer a more dependable way to prevent the back navigation

history.pushState(): This method allows you to add a new entry to the browser's session history without causing the page to reload. You can change the URL that appears in the address bar too, making it ideal for single-page apps or when you want to control navigation.

onpopstate event: This event is triggered whenever the active history entry changes, such as when the user clicks the browser's back or forward buttons. You can use it to respond to navigation events and, for example, prevent going back by forcing the user forward again with history.go(1).

The second page (page2.htm)

The page2.htm plays a very specific role: it's designed to trap the user on that page by disabling their ability to go back to the previous page (page1.htm) using the browser's back button or the keyboard's Backspace key.

<html>
<body>
    Click the browser back button <br /> 
    or hit the <b>Backspace</b> key.
</body>
</html>

The "page2.htm" is intentionally minimal. It doesn’t include any JavaScript itself. Instead, all the logic for blocking the back navigation is set up in page1.htm. The idea is that once the user clicks the link from page1 to page2, the browser history is manipulated so that when the user tries to go back, they’re immediately pushed forward again—keeping them stuck on page2.

Does it really work?

Yes, it really does work to a certain extent.

The technique using history.pushState() and the onpopstate event can effectively prevent users from navigating back, especially in modern browsers like Chrome, Firefox, and Safari. When the user tries to go back, the script pushes them forward again, essentially trapping them on the current page.

However, there are some caveats:

Blink-and-you’ll-miss-it flash: Users might briefly see the previous page flash on the screen before being redirected forward again.

Browser differences: Not all browsers handle this behavior identically. For example, Internet Explorer 10 doesn't support it reliably.

Not foolproof: Users with developer tools knowledge or those who disable JavaScript can still get around it.

Imagine this scenario: One of your users is midway through filling out an extensive registration form that collects vital details—name, contact, documents, preferences, maybe even payment information. Everything’s going smoothly… until, in a moment of distraction, they hit the Backspace key outside a text field, or accidentally click the browser’s Back button.

Now, let’s consider this question: If the user clicks the browser’s Back button, will the second page (page2.htm) retain the data they’ve entered?

To simulate and test this, we’ll add a simple text input field to page2.htm. By doing so, we can observe whether the input value remains intact after an attempted back navigation—especially if our forward-push prevention script redirects them right back to this page.

<html>
<body>
    Click the browser back button <br /> 
    or hit the <b>Backspace</b> key.

    <div style="padding:20px 0;">
        <input type="text" id='tb' value='' />
    </div>
</body>
</html>

Yes it works. 😃 Add more controls and check.

Is This Still Relevant Today?

Yes, its still relevant today, especially in specific use cases, but with some important caveats.

The technique of using history.forward() or the more robust history.pushState() with onpopstate is still supported by modern browsers like Chrome, Firefox, and Safari. Developers occasionally use it in scenarios where accidental navigation could be disruptive. For instance:

Online banking or transaction portals

Multi-step registration or checkout forms

Single-page applications (SPAs) where navigation is handled internally.

That said, this strategy is often considered user-unfriendly in general-purpose websites, as it goes against expected browser behavior. Modern best practices typically recommend:

Prompting users with a confirmation dialog if they try to leave mid-process.

Auto-saving form data using localStorage, sessionStorage, or cookies

Therefore, do consider you audience and UX goals before implementing it.

Conclusion

In the world of development, countless scripts come with their share of ifs and buts. Understanding their exact behavior and functionality isn't just optional, it's essential. Whether or not a snippet makes it into production, knowing how it behaves under real-world conditions equips us to build smarter, more resilient applications. Even the simplest script might unlock unexpected value across the diverse solutions we create.

← PreviousNext →