Client-side validation is a courtesy, not a guardrail

Client-side validation exists for one reason: to save the user a round trip. If someone types "abc" in a phone number field, telling them immediately is better than letting them submit the form, waiting for the server response, and then showing the error. That's it. That's the entire job.

The problem is that most sites treat client-side validation as if it's doing more than this. They rely on pattern attributes that reject valid input, write custom JavaScript validators that don't match the server's rules, show error messages that don't explain what went wrong, or skip validation entirely on some fields while over-validating others.

The patterns that fail

Overly strict phone validation. A regex that requires exactly 10 digits rejects international numbers, numbers with extensions, and numbers formatted with dashes or parentheses. The user's phone number is valid. Your regex is wrong.

Email validation theater. Checking for an @ symbol and a dot is about as much as client-side email validation should do. Regex patterns that try to fully validate RFC 5322 email addresses reject valid addresses like user+tag@domain.co.uk or addresses with IP literals. The server should validate email deliverability; the client should catch obvious typos.

ZIP code assumptions. Requiring exactly 5 digits excludes ZIP+4 format (12345-6789), Canadian postal codes, UK postcodes, and every other country's mail code format. If your form serves international users, the postal code field should accept freeform text with a reasonable length limit.

Password rules without clarity. "Password must be at least 8 characters and contain an uppercase letter, lowercase letter, number, and special character." Fine. But showing this as a single red error message after the user types doesn't help. Show which requirements are met and which aren't, in real time, so the user isn't guessing.

What an audit catches

A validation audit scans every form on a page and checks each input for:

Type attributes: Does the input use the correct HTML5 type (email, tel, url, number, date) so the browser provides the right keyboard on mobile and applies built-in validation?
Required marking: Are required fields marked with both the required attribute (for browser validation) and a visual indicator (for sighted users)?
Pattern consistency: If a pattern attribute is present, does it match what the server actually accepts? Patterns that are stricter than the server rejects valid input. Patterns that are looser than the server let invalid input through to a server error.
Error message quality: When validation fails, does the error message say what went wrong and how to fix it? "Invalid input" tells the user nothing. "Phone number must include area code" tells them exactly what to change.
Autofill compatibility: Do inputs with autocomplete attributes have validation rules that accept the format browsers auto-fill? If Chrome autofills a phone number as "(208) 555-1234" and your validation rejects parentheses, autofill makes the form harder to use, not easier.

The mobile keyboard gap

One of the most overlooked validation issues is the wrong keyboard. When an <input> has type="text" but collects a phone number, mobile users get a full QWERTY keyboard instead of a numeric dialpad. They have to switch keyboard modes, type the number, and possibly get a validation error because they accidentally included a letter.

Using type="tel" gives mobile users the phone dialpad. Using type="email" gives them the keyboard with @ and . keys prominent. Using inputmode="numeric" gives them a number pad for fields like credit card numbers or verification codes where type="number" would add unwanted spinner controls.

These aren't just convenience features. For users with motor impairments who struggle with precise key targeting, the right keyboard layout reduces errors significantly. For all users on mobile, the right keyboard is the difference between a quick form fill and a frustrating one.

Validation and conversion

Every unnecessary validation error is a potential abandonment. Baymard Institute's checkout usability research found that overly strict validation was one of the top causes of form abandonment, with users leaving because they couldn't figure out what format the site wanted.

The Form Conversion Audit measures the conversion friction of every form on a page, including validation patterns. The Form-Field Friction Estimator applies benchmark drop-off weights to each field based on its type and validation requirements. Together, they give you a clear picture of where validation is helping users and where it's driving them away.

For business owners building their first web presence, I discussed the balance between data quality and conversion friction in The $97 Launch. The short version: collect the minimum data you need, validate it gently, and let the server do the strict checking.

Fact-check notes and sources

RFC 5322 defines the syntax for internet email addresses. Many valid addresses are rejected by common regex patterns. Source: IETF RFC 5322, Section 3.4.1.
HTML5 input types (email, tel, url, number) provide built-in browser validation and mobile keyboard optimization. Source: WHATWG HTML Living Standard, Section 4.10.5.
Baymard Institute found overly strict validation among top causes of checkout form abandonment. Source: Baymard Institute, "Checkout Usability" benchmark study (updated annually, 2012-2024).
inputmode="numeric" attribute controls mobile keyboard without applying type="number" spin button behavior. Source: WHATWG HTML Living Standard, Section 6.8.1.

This post is informational, not development consulting advice.