FormsFree

Inline Validation

Tell users about input problems at the right moment — not while they're still typing, and not only after they submit.

6 states5 edge casesDesktop + Mobile

01The problem

Validate too early and users see “Invalid email” after typing one letter. Validate too late and they submit a long form only to find six errors, some scrolled out of view. Error messages like “Invalid input” don't say what's wrong or how to fix it. Good validation is mostly about timing and wording.

02When to use

Use when

Any form with constraints: required fields, formats, lengths, uniqueness
Sign-up, checkout, settings and record creation forms

Avoid when

Free-form fields with no constraints.
Constraints that depend on several fields together — validate those on submit, at the group level.

03Recommended UX

Statecraft recommendation

Validate a field when the user leaves it, then re-validate on every keystroke once it has shown an error so the message disappears the moment it's fixed. On submit, validate everything, move focus to the first error, and show a summary for long forms. Every message says what's wrong and how to fix it.

Validating on blur waits until the user thinks they're done, so it never interrupts typing.

Switching to live validation after an error rewards the fix immediately, which is when users want feedback.

“Use at least 12 characters” is actionable. “Invalid password” makes users guess.

04Interaction flow

01
Field untouched
Constraints shown as helper text, not errors.
02
User leaves field
Validate; show error if invalid.
03
User corrects
Live re-validation; error clears on fix.
04
Submit
Validate all; focus first error; summary if long.
05
Server validation
Uniqueness and business rules mapped to fields.
Result
- Submitted
- Field errors
- Form error

05Desktop behaviour

On desktop, errors appear directly below the field, replacing or joining its helper text, with the field border changed as a secondary signal.

Desktop rules

Show constraints up front as helper text (“At least 12 characters”).
Error text below the field, in red with an icon; border colour as a secondary cue.
For forms longer than one screen, show an error summary at the top on submit with links to each field.
Never disable the submit button to signal errors — let submit reveal them.

Constraints shown up front, errors after leaving a field, and messages that say how to fix the problem.

06Mobile behaviour

On mobile, the keyboard hides much of the form, so errors must be easy to find after submit and inputs must prevent errors where possible.

Mobile rules

Use input types and input modes so the right keyboard appears (email, number, tel).
On submit, scroll the first error into view above the keyboard and focus it.
Keep error text short — one line where possible.

The right keyboard for each field, and the first error scrolled into view above the keyboard after submit.

07States

Pristine
Helper text shows constraints; no errors.
Valid
No message; optional check for fields where success isn't obvious (username available).
Invalid
Error text below the field explaining the fix.
Checking
Async check running (e.g. username availability).
Submit errors
Summary with links; focus on first error.
Server error
Form-level message when the problem isn't tied to a field.

08Edge cases

EC-01
Autofill
The browser fills 8 fields at once.
Recommendation
Validate autofilled fields immediately (they won't be blurred) so problems show before submit.
EC-02
Async uniqueness check
Checking whether a workspace URL is taken.
Recommendation
Debounce, show a checking state, and ignore stale responses. Re-check on submit — availability can change.
EC-03
Server rejects a value the client accepted
The email domain is blocked by a server rule.
Recommendation
Map server errors back to the field with the same style, and focus it.
EC-04
Pasted values
A phone number is pasted with spaces and brackets.
Recommendation
Normalise formatting instead of rejecting it. Validate meaning, not keystrokes.
EC-05
Required optional fields
Most fields are required and marking each one adds noise.
Recommendation
Mark the minority: label optional fields “(optional)” when most are required.

09Microcopy

Password
Avoid
“Invalid password”
Prefer
“Use at least 12 characters”
Email
Avoid
“Invalid input”
Prefer
“Enter an email like name@company.com”
Uniqueness
Avoid
“Already exists”
Prefer
“lumen.yourapp.com is taken. Try lumen-team.”
Summary
Prefer
“2 fields need attention: Email, Password”

10Accessibility

Link errors to fields with aria-describedby and set aria-invalid="true".
On submit, move focus to the summary or the first invalid field.
Errors use text and an icon, not colour alone.
Don't announce errors on every keystroke — only on blur and submit.

11Developer notes

01
Share one validation schema between client and server so rules can't drift.
02
Track touched/dirty state per field to drive timing (blur first, then live).
03
Return server validation errors keyed by field path.
04
Normalise input (trim, format) before validating.

12Implementation prompt

For Claude Code, Codex or Cursor

Implement inline validation for the existing forms.

Requirements:
- Shared validation schema for client and server.
- Timing: validate on blur; once a field has an error, re-validate on each change; validate all on submit.
- Helper text shows constraints up front; error text below the field explains the fix.
- aria-invalid and aria-describedby on invalid fields; errors with icon + text.
- On submit: focus first error; error summary with links for long forms.
- Never disable submit to signal errors.
- Async checks debounced with a checking state, stale responses ignored, re-checked on submit.
- Server errors keyed by field path, rendered like client errors; form-level errors at the top.
- Autofilled fields validated immediately; pasted values normalised.
- Mobile: correct input types, scroll first error above the keyboard.

Do not redesign the existing interface.