Which Button Submitted the Form?

A single form can offer several submit actions. An editor might let someone save a draft or publish it. A form-level submit handler receives either action, but how does it know which one was requested?

The submit event targets the form, not the button. That makes sense when you consider that the event describes a form submission rather than an ordinary button click. In a submit handler, event.target identifies the form. The separate event.submitter property identifies the control that initiated the submission when one is available.

This example uses two named submit buttons. The handler prevents the normal navigation so it can show which action was requested:

<form id="editor" action="/articles" method="post">
  <label for="title">Title</label>
  <input id="title" name="title" required>
  <button type="submit" name="intent" value="draft">Save draft</button>
  <button type="submit" name="intent" value="publish">Publish</button>
</form>
<p id="status" role="status"></p>

<script>
  const form = document.querySelector('#editor');
  const status = document.querySelector('#status');

  form.addEventListener('submit', (event) => {
    event.preventDefault();
    const button = event.submitter;
    const intent = button?.name === 'intent' ? button.value : null;

    if (intent === 'draft' || intent === 'publish') {
      status.textContent = `Requested action: ${intent}`;
    } else {
      status.textContent = 'No recognized action was selected.';
    }
  });
</script>

The example reports an intent; it does not save or publish anything. In an application that sends the form itself, decide explicitly how the selected action travels with the rest of the data. When constructing FormData from a form, you can pass the submitter as the second argument so its eligible name and value are included. A submitter must be a submit button owned by that form; handle an absent submitter separately.

This matters because the two buttons share a name but have different values. A normal submission can include the value of the button that submitted it, rather than treating both buttons as selected. If JavaScript prevents that submission and builds a new request, it must preserve the action deliberately. Otherwise the server could receive the title without enough information to distinguish a draft from a publication request.

Do not assume the property always identifies a button. It can be null when a submission has no initiating button, including a submission requested without a specific submitter. A constructed event can also omit a submitter. The example handles that case without guessing that the person meant to publish.

Keyboard submission deserves testing too. Depending on the form and browser interaction, pressing Enter can activate the form’s default submit button. That means the first action in the markup can matter. Choose a safe default and test the keyboard path, not just mouse clicks.

Validation is another boundary. In the example, an empty required title normally stops interactive submission before the submit event reaches the handler. The status message therefore does not replace the browser’s validation feedback. If saving incomplete drafts is a requirement, design that action and its validation rules explicitly rather than assuming the handler will always run.

Finally, the button value is client-controlled. If the request reaches a server, validate the requested action and check that the authenticated person is allowed to perform it. The submitter helps the interface describe intent; it is not authorization.