Why That Ordinary Button Submitted Your Form

You add a button to reveal a little help text. The click handler works, but the form also tries to submit. The button did not need a submit handler to do that. Its HTML already gave it a job.

For an ordinary <button> associated with a form, leaving out type generally makes it a submit button. When activated, it can start the form submission process. The label does not change that: a button reading “Show help” can submit just as readily as one reading “Save”.

The fix is to say what each button is for:

<form action="/profile" method="post">
  <label>Display name <input name="displayName" required></label>
  <p id="name-help" hidden>Use the name you want others to see.</p>

  <button type="button" id="show-help">Show help</button>
  <button type="submit">Save profile</button>
  <button type="reset">Reset changes</button>
</form>

<script>
  document.querySelector('#show-help').addEventListener('click', () => {
    const help = document.querySelector('#name-help');
    help.hidden = !help.hidden;
  });
</script>

Here, type="button" makes the first button a general-purpose button. Its listener changes the help text without asking HTML to submit the form. type="submit" identifies the save action. type="reset" restores the form controls to their defaults, which is not necessarily the same as clearing them.

If the display name is empty, activating Save normally triggers browser constraint validation before submission. The browser can report that the required field needs a value, and the form will not proceed as if it were valid. The help button has a different purpose: someone should be able to reveal the instructions before filling in the field, without that action attempting to submit the form.

The precise rule has a wrinkle. The current WHATWG button definition calls the missing and invalid type defaults the Auto state. An Auto button is a submit button under specified conditions, including that neither command nor commandfor is present and its parent is not a select. So “every button without a type always submits” is too broad. For the ordinary form button in the example, however, the warning is exactly the one you need.

Form association matters too. A button is normally associated with an ancestor form, but the form attribute can associate a button elsewhere in the document with a form by ID. A button does not have to be visually inside the form to affect it. Inspect the element’s form property when the relationship is surprising.

There is a useful distinction between a button click and a form submission. A form may also be submitted through keyboard interaction, depending on its controls and the browser. Putting all save logic only on the button’s click handler can miss other submission paths. If your application handles submission in JavaScript, attach that logic to the form’s submit event and test both the button and keyboard paths.

If a form uses JavaScript to send data, handle its submit event and call preventDefault() when you intentionally take over submission. That is separate from choosing type="button" for a help action. One controls the submission workflow; the other prevents an unrelated control from starting it. Explicit types are a small habit that makes both the markup and the next debugging session easier to read.