How to prevent the Enter key from submitting a form

Why does Enter submit the form?

Browsers call it implicit submission. When you press Enter in a field, the browser acts as if you clicked the form's default button, which is the first submit button in the form. A <button> without a type counts: inside a form it is a submit button, and in our test Enter in a text field sent the form with that button's send=1. It is a convenience for search boxes and login forms, and a nuisance in a long form where people press Enter to move to the next field, or where a barcode scanner sends Enter after each code.

The rules have a few corners, so we checked them. On 6 November 2026 we built eight small forms and pressed Enter in each one in Chromium 153:

Three results are worth a second look. A form with a single text field submits on Enter even without a button, which is how search boxes work. A focused checkbox submits the form too, so “only text fields” is not the whole list. And with two submit buttons Enter used the first one, Delete, and sent action=delete. If your form has a destructive button, put the safe one first in the HTML and move it visually with CSS if you need to.

How to stop Enter from submitting in JavaScript

Catch the key before it becomes a submission. One keydown listener on the form covers every field inside it:

• Skip the textarea, so Enter still makes a new line in the message.
• Skip buttons, so someone who tabs to Send and presses Enter can still send.
• Skip event.isComposing. People typing Japanese, Chinese or Korean press Enter to confirm a word, and that Enter should never submit.

In our test this version blocked Enter in the text fields, kept the new line in the textarea, and the Send button still posted the form with all fields.

Use keydown. With preventDefault() on keyup the form was already on its way. keypress did block it, but that event is deprecated. Old snippets test event.keyCode === 13; that still worked in Chromium, where Enter reported key “Enter” and keyCode 13, but event.key is the readable, current property.

<form id="quote" action="https://formgong.com/submit" method="POST">
  <input type="hidden" name="access_key" value="fk_your_access_key">
  <label>Name <input name="name" required></label>
  <label>Email <input type="email" name="email" required></label>
  <label>Details <textarea name="message"></textarea></label>
  <button type="submit">Send</button>
</form>

<script>
  const form = document.getElementById("quote");
  form.addEventListener("keydown", (event) => {
    if (event.key !== "Enter") return;
    if (event.isComposing) return;                          // Enter that confirms a Japanese or Chinese word
    if (event.target instanceof HTMLTextAreaElement) return; // keep new lines in the message
    if (event.target instanceof HTMLButtonElement) return;   // Enter on the Send button still sends
    event.preventDefault();
  });
</script>

Two popular fixes that break something

We also ran two versions that show up often in tutorials.

• Skipping checkboxes and radios. Some fixes return early when the focused input is a checkbox or radio, to leave those keys alone. But Enter on a focused checkbox submits the form (row 7 of the table), and with that fix it still did. Our version blocks it, and the Space key still ticked the box afterwards.
• Blocking every Enter in the form. A listener that calls preventDefault() on every Enter, with no exception for the textarea, also stops new lines: we typed “line1”, Enter, “line2” into the message box and got line1line2.

Why not just preventDefault in the submit handler?

Because the submit event can't tell you how it started. We logged event.submitter in the submit handler: for an Enter in a text field it was the Send button, exactly the same as for a real click. Call preventDefault() there and you have also disabled the button, which is what happened in our test. You only find out when nobody can send the form.

The no-JavaScript route also has a cost. Removing the submit button, or making it type="button", stopped Enter in our test, but then the form only sends through your script. If that script fails to load, nobody can send it. There is no HTML attribute that switches implicit submission off, and CSS can't touch it either.

Keyboard users often press Enter to send a short login or contact form, so we would keep the block to places where a stray Enter costs something: a long multi-step form, a barcode scanner, a grid of inputs. Keep the Send button visible there.

Make Enter move to the next field instead

For data-entry forms the friendlier option is to make Enter do what people expect from it there: go to the next field, and submit only from the last one. In our test the first Enter moved the focus from the name field to the email field, and the second Enter sent the form. On phones, add enterkeyhint="next" to every field but the last and enterkeyhint="send" to the last one, so the on-screen key says what it will do.

form.addEventListener("keydown", (event) => {
  if (event.key !== "Enter" || event.isComposing) return;
  if (!(event.target instanceof HTMLInputElement)) return;
  const fields = [...form.querySelectorAll("input:not([type=hidden])")];
  const i = fields.indexOf(event.target);
  if (i < fields.length - 1) {
    event.preventDefault();
    fields[i + 1].focus();   // Enter moves on; on the last field it submits
  }
});

React, Vue and React Hook Form

The same listener works in any framework, because the key event comes from the browser. In React put it on the form: <form onKeyDown={(e) => { if (e.key === "Enter" && e.target.tagName !== "TEXTAREA" && e.target.tagName !== "BUTTON") e.preventDefault(); }}>. React Hook Form's handleSubmit runs on the submit event, so it can't tell an Enter from a click either; stop the key in onKeyDown as above and leave handleSubmit as it is. In Vue, @keydown.enter on the form with the same checks does the job. If only one field is the problem, say a search box inside a bigger form, @keydown.enter.prevent on that one input is enough and leaves the rest of the form alone.

What if a half-filled form gets through anyway?

Blocking Enter is about comfort, not safety. Someone with JavaScript off, or a bot, can still post a form with empty fields. The browser's required attribute stops most people, and the server should stop the rest.

If the form posts to Formgong, turn on field checks under Settings, then Protection, then Field checks. A post that misses a required field or has a broken email address is refused with a 422 that names each field, before anything reaches your inbox. And if people do send twice by pressing Enter and then clicking, our guide to stopping duplicate form submissions covers locking the button while the form sends.

The same account gives you an AI help chat that can answer the question that made someone stop halfway through the form, and a reviews widget for the page around it.

Did Enter behave differently for you?

If Enter submitted a form in a case we did not list, or our fix broke something like an autocomplete dropdown, tell us at support@formgong.com. We will test it and update the page.