Forms: event and method submit

Two pieces of the form story sit right next to each other and are easy to mix up. One is the submit event, which fires when a user tries to send a form. The other is the submit() method, which you call to send a form yourself. They point in opposite directions: the event is the browser telling your code “the user wants to submit,” and the method is your code telling the browser “send this now.”

The submit event is where validation lives. You catch it, look at what the user typed, and either let the form go through or stop it and handle things in JavaScript instead.

The submit() method goes the other way. You build or grab a form in code and fire it off to the server without waiting for a click.

User clicks / presses Enter

→

submit event

→

your handler validates

your code

→

form.submit()

→

server (no event)

The submit event flows from user to your handler; the submit() method flows from your code to the server.

Event: submit

A user can submit a form in two main ways:

Click an <input type="submit"> or an <input type="image">.
Press Enter while focused on an input field.

Both routes end at the same place: a submit event fires on the <form> element. That single entry point is what makes it convenient. You don’t need to wire up the button click and the Enter key separately; hook the form’s submit event once and you catch every path.

Inside the handler you inspect the data. If something’s wrong, show the error and call event.preventDefault(). That cancels the default action, so the form never leaves for the server and the page doesn’t reload.

Enter in a text field

click Submit button

↓ both ↓

submit event on <form>

data OK → form goes to server

preventDefault() → stays in JS

Two user actions, one submit event, one decision point.

In the form below, try both things: click into the text field and press Enter, then click the Submit button. Each one pops an alert, and the form goes nowhere because the handler returns false:

<form onsubmit="alert('caught it!');return false">
  First: focus this field and press Enter <input type="text" value="hello"><br>
  Second: click the button <input type="submit" value="Send">
</form>

Returning false from an inline onsubmit attribute is the old-school way to cancel the default action; it’s equivalent to calling event.preventDefault(). In a handler added with addEventListener, the return value is ignored, so there you must call preventDefault() explicitly.

Prefer preventDefault() over return false

Inline onsubmit="...return false" works, but mixing markup and logic gets messy fast. In real code, attach the handler in JavaScript and cancel like this:

form.addEventListener('submit', (event) => {
  if (!isValid(form)) {
    event.preventDefault(); // stop the form from being sent
  }
});

Only preventDefault() reliably cancels the submission when you use addEventListener.

Here’s that pattern working for real. The handler always calls preventDefault() so the page never navigates; then it decides whether the data is good enough to “send.” Submit it empty, then with a longer name, and watch the verdict change:

interactiveValidate on submit, then allow or cancel

Live example — Validate on submit, then allow or cancel

HTML

<form id="signup">
<label>Username (at least 3 characters)</label>
<input id="uname" type="text" placeholder="type here…" autocomplete="off">
<button type="submit">Sign up</button>
</form>
<p id="out" class="msg">Try submitting empty, then type a real name.</p>

CSS

form { display: grid; gap: 8px; max-width: 320px; }
label { font: 600 13px system-ui, sans-serif; }
input {
padding: 8px 10px; font-size: 14px;
border: 1px solid #cbd5e1; border-radius: 6px;
}
button {
padding: 8px 14px; font-size: 14px; font-weight: 600;
color: #fff; background: #6d28d9; border: 0;
border-radius: 6px; cursor: pointer; justify-self: start;
}
button:hover { background: #5b21b6; }
.msg { font: 13px system-ui, sans-serif; margin-top: 12px; color: #475569; }
.msg.bad { color: #9d174d; }
.msg.good { color: #166534; }

JavaScript

const form = document.getElementById('signup');
const uname = document.getElementById('uname');
const out = document.getElementById('out');

form.addEventListener('submit', (event) => {
event.preventDefault(); // never let the page reload here

const name = uname.value.trim();
if (name.length < 3) {
  out.textContent = '✗ Blocked — the form did not go anywhere.';
  out.className = 'msg bad';
} else {
  out.textContent = '✓ "' + name + '" is valid — this is where you would send it.';
  out.className = 'msg good';
}
});

The odd link between submit and click

Here’s a quirk worth knowing. When a form is submitted by pressing Enter inside a text field, a click event fires on the <input type="submit"> too, even though nobody clicked anything.

<form onsubmit="return false">
 <input type="text" size="30" value="Put the cursor here and hit Enter">
 <input type="submit" value="Send" onclick="alert('click')">
</form>

Focus the text field, press Enter, and the click alert appears. The browser synthesizes that click on the form’s default submit button as part of handling Enter. It looks strange, but it’s consistent behavior you can rely on.

Rather than an alert, this demo logs every event as it happens so you can see the order. Focus the field and press Enter — you’ll get a click on the button and a submit on the form. Then click the button directly and compare: the exact same two lines appear.

interactiveEnter fires a synthetic click, then submit

Live example — Enter fires a synthetic click, then submit

HTML

<form id="qform">
<input id="q" type="text" size="28" value="Focus me and press Enter">
<input type="submit" value="Submit">
</form>
<button id="clear" type="button">Clear log</button>
<ol id="log"></ol>

CSS

form { display: flex; gap: 8px; flex-wrap: wrap; }
input[type="text"] { padding: 7px 9px; border: 1px solid #cbd5e1; border-radius: 6px; }
input[type="submit"] { padding: 7px 12px; border: 1px solid #cbd5e1; border-radius: 6px; cursor: pointer; background: #f1f5f9; }
#clear { margin: 10px 0; padding: 5px 10px; font-size: 12px; border: 1px solid #cbd5e1; border-radius: 6px; background: #fff; cursor: pointer; }
ol { font: 13px ui-monospace, monospace; padding-left: 22px; color: #334155; }
li { margin: 3px 0; }

JavaScript

const form = document.getElementById('qform');
const btn = form.querySelector('input[type="submit"]');
const log = document.getElementById('log');
let n = 0;

function add(msg) {
const li = document.createElement('li');
li.textContent = ++n + '. ' + msg;
log.append(li);
}

btn.addEventListener('click', () => add('click on the Submit button'));
form.addEventListener('submit', (event) => {
event.preventDefault(); // stay on the page so we can keep logging
add('submit event on the <form>');
});

document.getElementById('clear').addEventListener('click', () => {
log.innerHTML = '';
n = 0;
});

Method: submit

Sometimes you want to send a form from code, not from a user gesture. Call form.submit() and the browser submits it to the server as if it had been triggered normally.

There’s one important asymmetry: calling form.submit() does not fire the submit event. The reasoning is that if your script is the one submitting, your script has already done whatever checking it needed. The event exists to give you a chance to intervene on a user’s action, and here there’s no user action to intervene on.

user

→

submit event fires

→

server

code

→

form.submit(): no event

→

server

A user submit passes through the event; form.submit() bypasses it.

A common use is building a form on the fly and firing it off. This example creates a stock-lookup form in memory, points it at a URL, fills in a field, and submits:

let form = document.createElement('form');
form.action = 'https://quotes.example.org/lookup';
form.method = 'GET';

form.innerHTML = '<input name="ticker" value="ACME">';

// the form must be in the document to submit it
document.body.append(form);

form.submit();

Note the comment: the form has to be attached to the document before submit() will work. A form that only exists in a detached variable won’t submit. That’s why the code appends it to document.body first.

Event vs. method at a glance

	`submit` event	`form.submit()` method
Direction	browser → your code	your code → browser
Triggered by	user click or Enter	a JavaScript call
Fires the `submit` event?	yes (it is the event)	no
Typical use	validate, then allow or cancel	build and send a form from script
Cancel with	`event.preventDefault()`	not applicable

Modern alternative: sending data without leaving the page

Manually creating a form and calling submit() reloads or navigates the page, since a classic submission is a full request. When you want to send data and stay put, fetch with a FormData body is usually the better tool:

let form = document.querySelector('form');
form.addEventListener('submit', async (event) => {
  event.preventDefault();
  let response = await fetch(form.action, {
    method: form.method,
    body: new FormData(form)
  });
  // handle response without a page reload
});

The submit event still does the same job here: it’s where you intercept the user’s action before the browser navigates away.

Summary lines to remember

The submit event fires on the <form> for both a submit-button click and Enter in a text field. Cancel it with event.preventDefault() (or return false in inline handlers) to keep the data in JavaScript.
Pressing Enter also produces a synthetic click on the form’s default submit button.
form.submit() sends the form from code and skips the submit event entirely; the form must be in the document first.
Watch for controls named after form properties like submit — they shadow the method.