How to Stop Your Webpage From Reloading When You Click a Form Button

You click a button to add an item, filter a list, or check an answer, and the whole page refreshes. Your scroll position is gone, the form is empty, and any work the page was doing resets. It feels like the button is working against you.

The reload is not a bug in your browser. It is the default behaviour of a form, built into HTML from the earliest days of the web. Once you understand that default, you have several clean ways to stop it, depending on whether you use plain HTML, JavaScript, or a framework.

Quick Answer

To stop the reload, change the button to type="button" if it does not need to submit anything. If it must submit, handle the submit event in JavaScript and call event.preventDefault() so you can process the data without leaving the page. One of those two changes removes the refresh in almost every case.

Why Clicking a Form Button Reloads the Page

A form exists to send data to a server and load the response. When you press a submit button, the browser sends the data to the URL in the form’s action and displays what comes back. If there is no action, it sends the data to the current page, which looks like a plain reload with a question mark or extra text in the address bar.

Here is the detail that catches many people: a button element inside a form is a submit button by default. You do not need to write type="submit" for the reload to happen. The absence of a type is enough. An input element behaves differently, because <input type="button"> never submits, while <input type="submit"> always does.

Signs the Reload Is a Form Submission

• The address bar gains a ? or field values after the refresh.
• Everything typed into the form disappears.
• The page jumps back to the top.
• The same button outside a form does not cause a reload.

If those signs match, you are not chasing a server fault or a browser glitch. You are seeing standard form behaviour, described in the MDN reference for the button element, which explains each button type clearly.

Method 1: Change the Button Type

This is the right fix when the button only does something on the page itself, such as opening a panel, adding a row, or running a calculation. It does not need to send data anywhere.

1. Find the button in your HTML.
2. Add or change the type so it reads <button type="button">Add item</button>.
3. Attach your JavaScript to its click event as before.
4. Reload the page and test. The click should now run your code with no refresh.

This small change is the most common fix in real projects. Many reload bugs come from buttons that were copied from a submit example and never adjusted.

Method 2: Prevent the Default Submit in JavaScript

Choose this method when the button should send data, but you want to handle that sending yourself, for example with fetch to an API, and update the page without a refresh.

1. Give the form an id, such as <form id="search-form">.
2. In your script, select the form and listen for its submit event, not just the button click.
3. Call event.preventDefault() as the first line of your handler.
4. Read the field values, send them with fetch, and show the result on the page.
5. Add a success and error message so visitors know the action worked.

A short handler looks like this: document.querySelector('#search-form').addEventListener('submit', function (event) { event.preventDefault(); }); Everything you add after that call runs without a page reload. Listening to the form’s submit event is better than listening to the button’s click, because visitors can also submit by pressing Enter inside a text field, and your handler should catch that path too.

Method 3: Check Framework and Library Behaviour

In React, Vue, and similar tools, forms still follow HTML rules underneath. If you attach a submit handler but forget to prevent the default, the browser reload wins. In React, your handler receives a synthetic event, and calling e.preventDefault() works the same way. Also watch for buttons inside component libraries: some render a real submit button even when they look like plain action buttons. Check the rendered HTML in developer tools rather than trusting the component name.

If your page uses a single-page app router, an unexpected reload is even more noticeable because it can reset app state. Our beginner’s guide to JavaScript event listeners explains how submit and click events flow, which helps when several handlers compete.

What Not to Do

Returning False From Old-Style Handlers

Older tutorials suggest onclick="return false". This can work in narrow cases, but it mixes behaviour into markup, is easy to break during edits, and does not cover Enter-key submissions reliably. Modern event listeners with preventDefault() are clearer and easier to maintain.

Removing the Form Element Entirely

Deleting the form tags stops reloads, but it also removes useful behaviour: Enter-to-submit, built-in validation, autocomplete, and accessibility semantics that screen readers rely on. Keep the form and control its behaviour instead.

Using a Link Styled as a Button

Swapping the button for an a tag with a # href creates new problems, including a jump to the top of the page and poor keyboard support. Buttons exist for actions; links exist for navigation. Keeping them separate avoids a fresh set of bugs.

Common Mistakes and Helpful Tips

• Fixing the click but not the Enter key: Always handle the form submit event so keyboard submissions follow the same path as button clicks.
• Calling preventDefault too late: Put it at the very start of the handler. If earlier code throws an error, the default reload can still happen.
• Two handlers fighting: A template script and your own script may both listen. Check for duplicate listeners when behaviour seems random.
• Forgetting feedback: When there is no reload, visitors need another signal. Show a message, spinner, or updated result so the page does not feel broken in a new way.
• Accidental submit in multi-step forms: Buttons labelled Back or Add often need type="button", while only the final step should use a real submit.
• Testing only with the mouse: Test with the keyboard as well, tabbing to fields and pressing Enter, to catch hidden submission paths.

The MDN page for the preventDefault method is a handy bookmark when you need to confirm exactly what the call stops and what it does not.

Conclusion

A page reload after a button click is simply a form doing its default job. If the button should not submit, set type="button". If it should submit on your terms, intercept the submit event and call preventDefault() first, then handle the data yourself. Keep the form element for its validation and accessibility benefits, give visitors clear feedback, and the mysterious refresh becomes a behaviour you control completely.

Frequently Asked Questions

Why does my page reload even though my button has no type submit?

Because a button inside a form defaults to submit behaviour when no type is given. The browser treats the missing attribute as an instruction to submit. Adding type="button" removes that default and stops the reload.

What does preventDefault actually do?

It tells the browser not to carry out the normal action linked to an event. For a form submit event, the normal action is sending the data and loading a new page. Your own code then decides what happens instead.

Should I listen to the button click or the form submit event?

Listen to the form submit event. It covers button clicks and Enter-key submissions in one place, so your prevention logic and your data handling stay consistent for every visitor, however they use the page.

Will type button stop my form from sending data to the server?

Yes, that button will no longer trigger a native submission. That is exactly what you want for on-page actions. If you later need to send the data, do it deliberately from your script with fetch when the visitor finishes.

My page still reloads after adding preventDefault. What else can cause it?

Check whether the handler is attached to the correct form, whether an error occurs before the preventDefault() line runs, and whether another script re-submits the form. Also confirm the button is not inside a second nested form created by a template or builder.