Form events

Forms send events

A person fills in a form in small steps. They type. They paste. They pick an option. They move to the next field. At the end, they send the form. Your JavaScript can react to each of these steps.

The browser tells your code about each step with an event: a short message that says "this just happened". You met events in Introduction to events. This lesson covers the events that forms send:

• input: the value just changed, while the person is still editing.
• change: the person has finished changing the value.
• submit: the person is sending the whole form.
• cut, copy, and paste: the person used the clipboard, the place where your computer keeps copied text.
• Focus events: the person moved into a field or out of it.

One rule matters a lot. These events report what the person does. Typing, pasting, voice typing, picking an option, choosing a file, ticking a checkbox, and the browser's autofill all count. When your own code sets a value, such as input.value = "Ada", no input or change event happens.

input is the live event. It runs every time the person changes the value. Typing a letter, pasting, deleting, undo, voice typing, and phone keyboard suggestions all count. Use input for things that should update while the person types, such as a character counter, a live preview, or a search filter.

change is the "done" event. When it runs depends on the kind of field:

• A text field, or a textarea (a box for several lines of text): change runs when the person leaves the field after changing it. Sometimes pressing Enter counts too.
• A checkbox, a radio button, a select menu, a date picker, or a file picker: change runs right away, because picking is already the final choice.

1const controls = form.elements;2form.addEventListener("input", logEvent);3form.addEventListener("change", logEvent);4 5function logEvent(event) {6  const target = event.target;7  const value = target.type === "checkbox" ? target.checked : target.value;8  addRow(event.type, target.name, value, event.inputType ?? "—");9}

Try the text field first. You get one input row for each letter you type. The change row waits until you press Tab or click somewhere else. Then try the checkbox and the menu. Each one gives its rows right away, because picking is already final.

For text edits, event.inputType says what kind of edit it was. For example: insertText for typing, insertFromPaste for pasting, or deleteContentBackward for Backspace.

The beforeinput event runs just before the edit happens. At that moment the value has not changed yet, so your code can still stop the edit. input runs after the edit, when the new value is already in the field. Both events have inputType for text edits.

const field = document.querySelector("#clipboard-field");
field.addEventListener("beforeinput", (event) => {
  console.log("before:" + event.inputType);
});
field.addEventListener("input", (event) => {
  console.log("after:" + event.inputType);
});

Type one letter in this field. Line 3 prints before:insertText first. Then line 6 prints after:insertText. A text editor app can use beforeinput to block an edit. For counters and previews, plain input is simpler.

const events = [];
events.push("checkbox:input");
events.push("checkbox:change");
events.push("select:input");
events.push("select:change");
console.log(events.join(" -> "));

This code writes down the order a browser usually uses. Ticking a checkbox gives input and then change, both at once. Picking from a select menu does the same. There is no "still typing" time in between, because the choice is already final.

Read each row from left to right: a question about your form, the event to use, and why.

1const log = [];Run2let value = "";3value += "h";4log.push("input:" + value);5value += "i";6log.push("input:" + value);7log.push("change:" + value);8log.push("focusout:" + value);9console.log(log.join(" -> "));

This step-through is a model: plain JavaScript that copies the order of the events, because it has no real form inside it. The order comes from a real test in Chrome. Typing h, typing i, and then pressing Tab gave input, input, change, and then focusout, the event for focus leaving. Browsers can differ a little when Enter is pressed, so test the forms you build.

The submit event belongs to the form, not to the button. Three things can start a submit:

• clicking a submit button,
• pressing Enter in a text field of the form,
• calling form.requestSubmit() from your code.

The event bubbles: a listener on a parent element hears it too. It is also cancelable: your code can stop what the browser would do next. If your code does not stop it, the browser does three things:

1. It checks the form's rules, such as required fields. This check is called constraint validation.
2. It sends the form's data to the server.
3. It loads the server's answer as a new page.

1form.addEventListener("submit", (event) => {2  event.preventDefault();3  const button = event.submitter;4  const intent = button?.value ?? "implicit";5  status.textContent = "Saved by " + intent + ": " + form.elements.title.value;6});7 8requestButton.addEventListener("click", () => form.requestSubmit());9skipButton.addEventListener("click", () => form.submit());

In the lab, pressing Enter in the Title field also submits the form. That works because the form has a submit button. A form with only one text field can also submit on Enter.

event.submitter is the button that started the submit. Here it tells Save draft apart from Publish. It can be null, for example after requestSubmit() with no button given. So read it with ?., the optional chaining operator. It gives undefined instead of an error when the left side is null.

1form.addEventListener("submit", (event) => {2  event.preventDefault();3  const submitter = event.submitter;4  const data = new FormData(event.currentTarget);5  sendForm(data, submitter?.value ?? "save");6});

1. Line 1 listens for submit on the form.
2. Line 2 calls event.preventDefault(), so the browser does not load a new page.
3. Line 3 keeps the button that started the submit.
4. Line 4 collects the name and value of every field with new FormData(...). event.currentTarget is the form, the element the listener is on.
5. Line 5 sends the data. If there was no button, it uses "save".

Two methods with similar names do very different things:

• form.requestSubmit() acts like a click on a submit button. It checks the form's rules and sends the submit event.
• form.submit() is older. It sends the form at once. It skips the rule check, and no submit event happens.

const demo = document.createElement("form");
demo.innerHTML = '<input name="name" required><button>Send</button>';
document.body.append(demo);
const target = document.createElement("iframe");
target.name = "submit-target";
target.hidden = true;
document.body.append(target);
demo.target = target.name;

demo.addEventListener("submit", (event) => {
  event.preventDefault();
  console.log("requestSubmit -> submit event");
});

demo.requestSubmit();
console.log("requestSubmit -> blocked by validation");
demo.elements.name.value = "Asha";
demo.requestSubmit();
demo.submit();
console.log("submit() -> no submit event");

The first requestSubmit(), on line 15, is blocked, because the required name field is empty. Line 17 fills in the name. Now the second requestSubmit(), on line 18, passes the check, and the listener prints its message. Line 19 calls submit(), which skips both the check and the listener. Lines 4 to 8 send that submit to a hidden iframe (a small page inside the page), so it can't leave this lesson.

form.addEventListener("reset", () => {
  console.log("reset requested");
});

form.reset();
console.log("The reset event runs before the controls return to defaults.");

The reset event runs when the form is asked to go back to its starting values. It runs before the fields change back, so your code can still cancel it. Line 5 calls form.reset(), which starts a reset from code. Don't mix this up with clearing one field by setting its value. That sends no event at all.

const field = { value: "Ada" };
field.value = "";
console.log(field.value);
console.log("No input or change event was created by the assignment.");

To keep it short, this example uses a plain object in place of a field. Line 2 sets the value to an empty string, and line 3 prints that empty value. But nothing told any listener about it. If your own code owns the data, update that data directly. Don't fake a user event just so other listeners notice.

The clipboard is the place where your computer keeps text you copied. The cut, copy, and paste events are ClipboardEvents. While the action happens, the event has a clipboardData object:

• On paste, read the text with event.clipboardData.getData("text/plain"). "text/plain" asks for plain text, with no colors or bold.
• On copy or cut, set the text with clipboardData.setData(...).

If you call preventDefault() on paste, the browser does not put the text in for you. Then your listener must put in the text you want.

const actions = ["copy", "cut", "paste"];
console.log(actions.join(" -> "));
console.log("clipboardData is available during each user action");

Each action does something different to the field:

• copy leaves the field as it is.
• cut removes the selected text, after the event.
• paste puts text where the cursor or the selection is.

All three give you clipboardData only during the person's action. It is not a way to read the clipboard at any time.

1field.addEventListener("paste", (event) => {2  const text = event.clipboardData.getData("text/plain");3  const clean = text.trim().replace(/\s+/g, " ");4  event.preventDefault();5  field.setRangeText(clean, field.selectionStart, field.selectionEnd, "end");6});7 8field.addEventListener("copy", (event) => {9  const selected = field.value.slice(field.selectionStart, field.selectionEnd);10  event.clipboardData.setData("text/plain", selected + "\nSource: demo field");11  event.preventDefault();12});

The paste listener does four things:

1. Line 2 reads the pasted text.
2. Line 3 cleans it. trim() removes the spaces at both ends. replace(/\s+/g, " ") turns each run of spaces, tabs, or new lines into one space.
3. Line 4 stops the normal paste.
4. Line 5 puts the clean text in with setRangeText, in place of whatever is selected.

The copy listener, on lines 8 to 12, adds a line, "Source: demo field", under the copied text.

Never read a person's clipboard when the page loads. To copy from a button, such as "Copy link", use navigator.clipboard.writeText("text"). It works only after a click or a key press, and only on a secure page, such as one served over https.

Focus is where your keyboard typing goes. Only one field has focus at a time. Four events report focus moving:

• focus: a field got focus.
• blur: a field lost focus.
• focusin: the same as focus, but it bubbles.
• focusout: the same as blur, but it bubbles.

Because focusin and focusout bubble up to the form, one listener on the form hears every field. It can highlight the group of fields the person is in. It can also check a field when the person leaves it.

1form.addEventListener("focusin", (event) => {2  event.target.closest("fieldset")?.classList.add("active");3});4 5form.addEventListener("focusout", (event) => {6  event.target.closest("fieldset")?.classList.remove("active");7  validateField(event.target);8});9 10form.addEventListener("input", (event) => {11  if (event.target.dataset.touched === "true") validateField(event.target);12});

A polite way to check a field has three steps:

1. Don't show an error before the person has used the field.
2. When they leave the field (blur or focusout), mark it as "touched" and check it.
3. After that, check it again on every input, so the error goes away as soon as they fix it.

The autofocus attribute puts focus in a field when the page opens. It can help on a tiny page, like a search page. But it can also move a screen reader user away from where they were reading, or open the phone keyboard when nobody asked for it. Use it rarely, and test it.

Each row is one focus event: whether it bubbles up to the form, and a good use for it.

Where you will use this

Real forms use these ideas together:

• A search box shows new results on input.
• A settings page saves a menu choice on change.
• A sign-up form stops the normal submit, sends the data with JavaScript, and shows a "Thanks" message on the same page.
• A payment form cleans a pasted name, checks fields on blur, and checks them again on input.

1search.addEventListener("input", () => {2  renderResults(search.value);3});4 5email.addEventListener("focusout", () => {6  email.dataset.touched = "true";7  showEmailError(email.validity.valid ? "" : "Enter an email address.");8});9 10email.addEventListener("input", () => {11  if (email.dataset.touched === "true") showEmailError("");12});13 14form.addEventListener("submit", (event) => {15  event.preventDefault();16  save(new FormData(form), event.submitter?.value ?? "save");17});

1. Lines 1 to 3: every edit in the search box shows new results.
2. Lines 5 to 8: when focus leaves the email field, mark it as touched. Show an error if the email is not valid. email.validity.valid is true when the field passes its rules.
3. Lines 10 to 12: once the field is touched, each new edit clears the error.
4. Lines 14 to 17: the form stops the normal submit and saves the data itself.

Keep what the browser already does well, unless you have a good reason to replace it. People rely on labels, the Tab key order, the browser's rule checks, and the normal submit. Your JavaScript should add to these, not remove them.

• "input runs only for the keyboard." It also runs for paste, drag and drop, undo, voice typing, and any other change the person makes.
• "change always comes later than input." For checkboxes, radio buttons, and menus, both run at once from the same choice.
• "Setting .value sends an event." When your code sets a value, neither input nor change runs.
• "Submit listeners go on buttons." Put them on the form. Find the button with event.submitter.
• "form.submit() is the same as clicking submit." It skips the rule check and the submit event. requestSubmit() is the one that acts like a click.
• "Code can read the clipboard at any time." Browsers allow it only during a person's action, with permission, on a secure page.

Key takeaways

• input runs on every change the person makes. change runs when the value is final.
• submit runs on the form. It bubbles, your code can cancel it, and event.submitter tells you which button started it.
• requestSubmit() acts like a real submit. form.submit() skips the rule check and the submit event.
• Clipboard events give you clipboardData during the person's action. preventDefault() on paste stops the normal paste.
• focusin and focusout bubble, so one listener on the form can highlight groups and check fields.

Final definition: Form events are the browser's messages about what a person does in a form: editing, finishing a value, sending, using the clipboard, and moving focus.

Up next: Form validation.