Field validation is the check a form runs on each piece of information someone enters, such as an email address, phone number or postcode, to confirm it is present and in a usable format before the form is sent. Good validation catches genuine mistakes and explains how to fix them; bad validation rejects perfectly valid answers and loses you the enquiry.
How field validation works
There are two layers. Client-side validation runs in the visitor’s browser, through built-in HTML attributes such as required and type="email" or through JavaScript, so feedback appears instantly. Server-side validation runs when the form reaches your website’s server, and it is the layer that actually protects your data, because anything in the browser can be bypassed. A sound form uses both: the browser layer for a helpful experience and the server layer for safety.
Timing matters as much as the rules. Inline validation shows feedback beside the field, usually once the person moves on to the next one. Validation on submit waits until they press the button, then points to every problem. Checking each keystroke while someone is still typing is the version that annoys people, because it marks an email address as wrong before they have finished entering it.
Each check also needs an error message. A useful message says what went wrong and how to put it right, for example “Enter a UK mobile number, such as 07700 900123”, and it sits next to the field rather than only in a red banner at the top of the page.
Why it matters
Overly strict validation is one of the most common reasons I find for people giving up on a form halfway through. UK input causes particular trouble when forms come from templates built for another country. UK postcodes have several shapes (SW1A 1AA, M1 1AE, B33 8TH, EC1A 1BB), may be typed with or without the space and in lower case, and a field expecting five digits rejects every one of them. Phone numbers arrive as 07, +44 7 or 0044 7, with or without spaces and brackets; geographic landlines begin 01 or 02, and many business numbers begin 03. A form that refuses any of those is turning a willing customer away at the very last step.
Validation also protects lead quality. Catching a mistyped email domain or a missing digit means the enquiry you receive is one you can actually answer, which matters when you are paying per click to bring people to the form.
Common mistakes
- Postcode or phone patterns copied from a US template, so valid UK entries fail.
- Rejecting input that could simply be tidied: spaces in a phone number or a lower-case postcode can be reformatted automatically.
- Vague messages such as “Invalid input”, or messages that appear only at the top of a long form.
- Wiping everything the person typed when the page reloads with an error.
- Showing errors only with a red outline, which people with colour blindness can miss and screen readers may not announce. The WCAG accessibility guidelines expect errors to be identified in text.
- Relying only on browser checks, which leaves the server open to junk and spam submissions.
How to act on it
Fill in your own forms on a phone using awkward but valid UK details: a postcode without a space, a number starting +44, a hyphenated surname, an email address containing a plus sign. Note every rejection and every message that does not explain itself. If you have form analytics in place, look for the field where people most often trigger errors or stop.
Then relax anything that does not need to be strict. Normalise formats on the server instead of forcing visitors to match them, validate when someone leaves a field rather than while they type, and write messages in plain English beside the field with an example of what is expected. Clear microcopy under a field often prevents the error altogether. For pages that receive paid traffic, I test every form as part of building landing pages for ad campaigns, because a rejected postcode wastes a click you have already paid for.