What is form validation?

Two jobs in two places

Checks in the browser and checks on the server exist for different reasons, and a form needs both. Browser checks are about the respondent: they catch a missed question or an impossible date while the person is still looking at the field, which is faster and kinder than a rejection after pressing submit. Server checks are about trust. MDN says plainly that client side validation should not be considered an exhaustive security measure, because it is too easy to bypass, and the OWASP input validation guidance adds that anything done in JavaScript can be circumvented by somebody who turns it off or sends the data directly. Whatever the browser allows through, the server has to decide again before the answer is stored.

The checks worth having

OWASP separates two levels. Syntactic validation checks that a value has the right shape, such as a date that is a real date or a postcode made of digits. Semantic validation checks that it makes sense in context, such as an end date that falls after the start date or a quantity that does not exceed stock. Most forms need a small set of syntactic rules: required answers present, numbers within a sensible range, text within a length that fits wherever it is going, files of an expected type and size, and choices restricted to the listed options. Semantic rules usually belong in the system that receives the data, because that is where the context lives, and they are where the most useful error messages come from. Keep the list short. Every rule is a chance to reject somebody who was trying to give a real answer, so each one should protect something specific: a record that would otherwise be unusable, a system that would otherwise break, or a follow up email that would otherwise be needed.

Be strict about meaning, relaxed about format

The W3C forms tutorial advises being liberal with input, because people write phone numbers, dates and postcodes in many legitimate ways. The GOV.UK Design System makes the same point with postcodes, which should be accepted with or without a space. The better approach is to tidy the value before checking it: remove spaces from a card number, trim the ends of an email address, accept lower case where upper case is stored. Rules that reject real answers are the worst kind of validation. OWASP gives the example of a denylist that blocks an apostrophe and so rejects a surname like O'Brian, and the same thing happens with hyphenated names, long addresses and international phone numbers.

Error messages that help

WCAG 2.2 success criterion 3.3.1 requires that a detected error is identified and described to the user in text, and 3.3.3 adds that a suggestion for fixing it should be offered where one is known. In practice that means the message names the field, says what is wrong and says what would be right: enter a date after the start date, rather than invalid input. GOV.UK recommends an error summary at the top of the page with focus moved to it, a message beside each field, and keeping everything the person already entered. It also turns off the browser's built in messages with novalidate so that every error looks and reads the same way.

Validation in this builder

The Validation settings on a field offer a Required Field switch, minimum and maximum length on short and long text, and minimum and maximum value on number fields, while file uploads have their own limits. The table above shows where each rule runs. Two gaps are worth knowing before you rely on them. A conversational number field does not stop an out of range value in the browser, so the range is only enforced when the form is submitted. And there is no regex pattern setting, so a format such as a membership number cannot be enforced by the form itself. On every submission the server also drops answers for any field that is not part of the published version the person filled in.

Questions people ask