The
input
event fires when a control’s value changes from a user action. Learn
addEventListener vs oninput, InputEvent fields,
how it differs from change and beforeinput, and five try-it labs.
01
Kind
Instance event
02
Type
InputEvent / Event
03
When
After value changes
04
Handler
oninput
05
Targets
input · textarea · select
06
Status
Baseline widely available
Fundamentals
Introduction
Every keystroke in a text box, every checkbox toggle, and many
<select> picks update a control’s value. The
input event fires after that user-driven change so you can react
immediately—live search, character counters, password strength meters, and more.
MDN: it also applies to contenteditable hosts and designMode.
It does not fire when you assign element.value in JavaScript.
💡
Beginner tip
Use input for “as the user types” updates. Use
change when you only care about a committed value (blur / Enter /
finished selection). Use beforeinput when you need to inspect or block
an edit before it applies.
Concept
Understanding input
An instance event that answers: “Did the user just change this
control’s value?”
Fires after user-driven value changes on <input>, <textarea>, <select>, and editable hosts.
InputEvent for text-accepting fields; may be a plain Event for some other controls.
Handler — oninput or addEventListener("input", ...).
Not fired by programmatic value assignments.
Checkbox / radio — should fire on toggle per HTML; historically uneven—prefer change if you need wide legacy safety.
Baseline Widely available on MDN (since January 2020).
Foundation
📝 Syntax
Use the event name with addEventListener, or set the handler property:
true during IME composition (between compositionstart/end)
dataTransfer
Rich/plain data for some paste or drag edits
Compare
⚖️ input vs change vs beforeinput
Topic
input
change
beforeinput
Timing
After each value change
When value is committed
Before the value changes
Keystrokes
Fires per edit
Usually waits for blur / Enter
Fires before each edit
Cancelable?
No — already applied
No (value already decided)
Often (not always)
Best for
Live UI / counters / search
Final committed value
Validate / block early
Caveat
⚠️ Programmatic Changes Do Not Fire input
MDN notes that the input event is not fired when JavaScript
changes an element’s value programmatically. If your app updates a field
in code and other logic must react, call that logic yourself (or dispatch a synthetic
InputEvent carefully).
For checkbox / radio, prefer also listening to change if you support older
environments where input was historically inconsistent.
input is marked Baseline Widely available on MDN. Logos use the shared browser-image-sprite.png sprite from this project. Listening for user-driven value changes is a core form pattern across engines.
✓
Baseline · Widely available
Element input
Fires after user-driven value changes on form controls and editable hosts.
FullWidely available
Google ChromeFull support
Yes
Mozilla FirefoxFull support
Yes
Apple SafariFull support
Yes
Microsoft EdgeFull support
Yes
OperaFull support
Yes
Internet ExplorerSupported (legacy; InputEvent details vary)
Partial
inputBaseline
Bottom line: Safe default for live form UX. Use change for committed values and beforeinput when you must inspect edits early.
Wrap Up
Conclusion
The input event is your go-to signal for “the user just changed this
value.” Use it for live UI, prefer change for commits, and reach for
beforeinput when you need to act before the edit lands.
Debounce expensive work (API search) inside the handler
Prefer addEventListener in production code
❌ Don’t
Expect input when you set value in JavaScript
Confuse input with change for keystroke UX
Assume checkbox/radio history is identical in every old browser
Block typing with preventDefault on input (too late—use beforeinput)
Overwrite oninput if you need multiple listeners
Summary
Key Takeaways
Knowledge Unlocked
Five things to remember about input
User changed the value—react live after the edit.
5
Core concepts
📱01
After the edit
value already updated
Trigger
📄02
InputEvent
data · inputType
API
⚡03
vs change
every keystroke
Compare
🔄04
beforeinput
inspect earlier
Pair
🎯05
Baseline
widely available
Status
❓ Frequently Asked Questions
It fires when the value of an <input>, <textarea>, or <select> changes as a direct result of a user action (typing, checking a box, picking an option). It also applies to contenteditable hosts and designMode.
No. MDN marks Element input as Baseline Widely available. It is not Deprecated, Experimental, or Non-standard.
For text-accepting <input> and <textarea>, the interface is InputEvent. For other controls, it may be a plain Event. InputEvent fields include data, inputType, isComposing, and dataTransfer.
input fires every time the value changes (for example each keystroke). change fires when the value is committed — such as pressing Enter in some fields, blurring a text control, or selecting an option from a list.
beforeinput fires before the value changes (and is often cancelable). input fires after the value has already changed. beforeinput does not fire on <select>; input can.
No. Setting element.value in script does not fire the input event. Only user-driven changes (and some browser UI actions) do.
Did you know?
Setting input.value = "hello" in script silently updates the field
without an input event. If other code listens for input, call it
yourself after programmatic updates.