Form Validation UX: Reducing Friction and Errors
When to validate, what to say when it fails, and the aggressive validation pattern that rejects real addresses.
On this page
The short version
- Validate on blur, not on every keystroke. Marking a field invalid while someone is still typing it is telling them they are wrong before they have finished.
- Over-strict email patterns reject real addresses. Plus signs, apostrophes, long and unusual domains are all valid, and the regexes that block them are widespread.
- The error message must say what to do, not what happened. "Invalid input" describes the system's opinion; "This needs an @ symbol" describes the fix.
Validation exists to help someone submit successfully, not to enforce correctness for its own sake. That framing settles most of the design decisions, and it is the opposite of how validation is usually implemented — as a gate that reports failure.
Three questions decide the experience: when to check, what to accept, and what to say when it does not pass.
When to check
Not on every keystroke. Someone typing an address is in an invalid state for almost all of it, and flagging that in real time means the field spends its life marked red while they work.
Validate when the field loses focus, and again on submit. That gives the person a chance to finish before being told anything.
The exception is re-validating a field that has already failed. Once an error is showing, checking as they type lets the error clear the instant it is fixed, which feels responsive rather than nagging. Check late, clear early.
Timing, by state
| Field state | When to validate | Why |
|---|---|---|
| Untouched | Never | Nothing has been attempted |
| Being typed, first time | Never | Invalid for most of the typing |
| Lost focus | Now | They have finished with it |
| Showing an error, being retyped | On each keystroke | So the error clears the moment it is fixed |
| Submit pressed | All fields | Last chance to catch anything |
What to accept
The only reliable proof that an address works is sending to it. Everything before that is a heuristic, so the heuristic should be permissive and the send should be the check.
A minimal client-side rule — non-empty, contains an at sign with characters either side, contains a dot in the domain part — catches genuine typos like a missing at sign and rejects almost nothing legitimate.
Real-time verification services sit above this and check whether the domain exists and sometimes whether the mailbox does. They are worth it at scale and they need a failure mode: if the service is unreachable, accept the address rather than blocking every signup while an API is down.
Catching the typo that is not an error
The most common real problem is not an invalid address, it is a valid address with a mistyped domain — gmial, hotmial, yaho. These pass every syntax check and bounce on the first send.
A suggestion, not a rejection, is the right response: "Did you mean name@gmail.com?" with the corrected version as a single click. It fixes the actual problem without blocking anyone whose unusual domain merely resembles a common one.
Error messages
Describes the failure
- "Invalid input"
- "This field is required"
- "Email format incorrect"
- "Error: 422"
Describes the fix
- "This needs an @ symbol"
- "We need an email address to send it to"
- "Did you mean name@gmail.com?"
- "Something went wrong at our end — try again?"
Where the message goes
Next to the field it concerns, not in a summary at the top of the form. A summary requires the reader to map an error onto a field, and on a one-field form it is absurd.
It also needs to be announced to assistive technology, which means the error text is associated with the input and the field is marked invalid — otherwise a screen reader user is told nothing at all and simply cannot submit.
Colour alone is not a message. A red border tells you something is wrong somewhere in the vicinity; it does not say what, and it says nothing to anyone who cannot distinguish it.
Validation check
- Nothing is validated while the field is being typed for the first time
- Errors clear as soon as they are fixed
- The email rule accepts plus signs, apostrophes and long domains
- A domain typo produces a suggestion, not a rejection
- Messages say what to do, not what happened
- The message sits beside the field and is announced to screen readers
- A verification service being down does not block signups
Frequently asked questions
Should I use the browser's built-in validation?
As a baseline, yes — it works without JavaScript and it is permissive. Its messages are generic and unstyled, so most forms enhance on top of it rather than replacing it.
Is a confirm-your-email second field worth it?
Rarely. It roughly doubles the typing, most people paste the same value into both, and it catches almost nothing a typo suggestion would not have caught more cheaply.
What about blocking disposable addresses?
Possible, and it costs you some legitimate privacy-conscious subscribers. If the address never engages it will be removed by your own hygiene rules anyway, which is a gentler filter than refusing at the door.