Conversion and UX

Field Validation

Also called form validation, input validation

Rules that check what somebody types into a form and tell them, before submission, whether it will be accepted.

Quick facts: Field Validation

Category
Conversion and UX
Also called
form validation, input validation
Level
Intermediate
Affects
Form completion, lead quality, enquiry volume
Where to see it
Browser developer tools, form analytics, session recordings
In this article4
  1. How field validation works
  2. Why field validation matters
  3. Where field validation goes wrong
  4. How to act on it

How field validation works

Validation is the set of rules a form applies to each answer. Some rules are about format — an email address needs an at sign and a domain, a date must be a real date. Some are about presence: this question must be answered before the form will send. Some are about the business: a phone number the sales team can actually ring, a budget within the range you work in.

The checks run in two places. In the browser, immediately, so the visitor is told while they are still looking at the field. On the server, after submission, because anything running only in the browser can be bypassed and cannot be trusted for security. Both are needed: the browser check is for the honest visitor’s convenience, the server check is for correctness and safety.

Why field validation matters

Badly timed validation is one of the quietest causes of lost enquiries. A field that turns red the moment the cursor enters it tells somebody they are wrong before they have typed anything. A form that only reveals its complaints after submission makes the visitor scroll back and hunt. Either way people give up, and because the form never sent, nothing about the loss appears in your reporting.

It also decides the quality of what reaches you. Loose rules fill the inbox with unusable phone numbers and test entries. Rules that are too strict reject genuine people — which in Nepal usually means a phone number written with a country code, with a leading zero, or with spaces, and an international enquiry rejected because the postcode field expects a local format.

Where field validation goes wrong

The common faults are all about timing and wording. Validating on every keystroke; validating on focus rather than on leaving the field; showing a message that names the rule rather than the fix, such as “invalid input” instead of “this needs to include an at sign”. Then there is the layout problem: an error message that appears above the field pushes everything down, so the visitor loses their place.

Two more are worth naming. Silently trimming or reformatting what somebody typed leaves them unsure what was actually recorded. And a validation error that clears the field, or the whole form, on failure is the fastest way to lose a lead who had nearly finished.

How to act on it

Validate when the visitor leaves a field, not while they are typing, and revalidate as they correct it so the message disappears the moment the input is right. Write messages that state what to do next, place them beside the field they belong to, and never clear an entry the visitor has already made.

Be generous with formats. Accept phone numbers with spaces, dashes and country codes and normalise them yourself rather than refusing them. Only make a question required if you truly cannot proceed without it — every required field is a chance to be turned away. Then test the form on a phone, submit a deliberately wrong entry to see what a stranger sees, and check what your error handling does when the server rejects something the browser allowed. If enquiries have dropped without an obvious cause, the form is the first place I check on a conversion rate optimisation job.

Do and do not

Do

  • Validate when the visitor leaves a field, not while typing
  • Write messages that say how to fix the entry
  • Repeat every browser check on the server

Do not

  • Reject phone numbers containing spaces, dashes or country codes
  • Clear a field or a form when validation fails
  • Mark a field required unless you genuinely cannot proceed

Questions people ask about this

When should a form show a validation error?

When the visitor leaves the field, not while they are typing and not the instant the cursor arrives. Checking on every keystroke marks an incomplete entry as wrong before it can possibly be finished. Once an error is showing, recheck as the person edits so the message clears as soon as the input becomes valid, which confirms the correction worked.

Why are real enquiries being rejected by my form?

Usually because a format rule is stricter than reality. Phone fields that reject spaces, dashes or a country code turn away genuine callers, and postcode or state fields built for one country block everyone else. Accept a broad range of input and tidy it up on your side after submission, rather than asking the visitor to guess your preferred format.

Is browser validation enough on its own?

No. Anything running in the browser can be disabled or bypassed, so it protects convenience but not correctness. Always repeat the checks on the server before storing or acting on a submission. Treat the browser layer as a courtesy that helps honest visitors get it right first time, and the server layer as the rule that actually decides what is accepted.

Related terms

Found this useful?

Share it, or ask an AI to summarise it

Back to the glossary

Knowing the term is the easy part

Applying it to your own site and budget is the work. Book a call and I will tell you what actually applies to you.