Forms and Validation

How it works

Behind every Create account or Place order button, the same journey happens:

Client-side vs server-side validation

Client-side validation is a convenience for the user. Server-side validation is protection for the business. A developer can forget to add a rule to the app, the iOS and Android apps can have different rules, an old app version can have no rules at all, and anyone can send a request with a tool like Postman or change it on the way with a proxy toolProxy toolA program that sits between the app and the server so you can watch and change network traffic.Open in glossary →. Only the server sees every request.

Anatomy of a good form

Labels, placeholders and help text

The label says what to enter; help text says how. Both stay visible while the user types. A placeholder is at most an extra example, because it vanishes on the first keystroke and often has low contrast (more on the Text Field page). Put formats and rules before the field (“At least 8 characters”, “For example 27 3 1995”): users shouldn’t have to fail once to learn the rules.

Required and optional

Pick one convention and use it everywhere. Most forms have fewer optional fields, so many teams mark those with “(optional)” and say so at the top. If the team uses an asterisk (*) for required fields instead, it must be explained (”* required”) and announced by screen readers, not just a red star. Test that what’s marked required is what’s actually required: a field marked optional that blocks submit, or a “required” field the server happily accepts empty, is a bug.

Grouping and order

Related fields belong together under a heading: “About you”, “Delivery address”, “Payment”. Screen readers should announce the group’s heading when you enter it. The order should match how people think (name before address, street before city), and the keyboard’s Next or Tab key should follow the same order (focus orderFocus orderThe order in which the Tab key moves through interactive elements.Open in glossary →). One column is easier to scan than two, especially on phones.

Input types and mobile keyboards

The field type decides which keyboard appears on a phone:

A keyboard is only a hint: people paste, use hardware keyboards and autofill, so a “numbers only” field still needs validation. The Text Field page has a live keyboard demo.

Autocomplete and autofill

Browsers, iOS, Android and password managersPassword managerA tool that stores credentials and fills them into login forms, like Apple Passwords, Google Password Manager or 1Password.Open in glossary → can fill a whole form in one tap, but only if each field says what it contains. On the web that’s the autocomplete attribute: name, email, tel, street-address, address-level2 (city), postal-code, country, bday, new-password, one-time-code and more. The Text Field page has a table of the most common hints.

What to test:

• AutoFill puts each value in the right field. A wrong token is easy to miss in code review: the city lands in the postcode, the surname in the first name.
• Autofilled values pass validation. Autofill can add a country code, a trailing space or a format your rules don’t expect.
• The form notices the values. Some forms only react to typing, so autofilled fields still count as “empty” or the button stays disabled.
• Sign up offers a strong password and the new password is saved to the password manager afterwards (autocomplete="new-password").
• Fields about the user have tokens. On the web this is a WCAG requirement: 1.3.5 Identify Input Purpose (AA).

When to validate

There are three moments to check a field. Each has trade-offs (try them live on the Text Field page):

Whatever the team chooses, test that it’s consistent across the form, that errors clear as soon as the value is fixed, that tapping into an empty field and out again doesn’t immediately paint everything red, and that submit always validates everything, including fields the user never touched.

Error messages that help

A good error message:

• Is specific and tells the user what to do. “Enter a postcode like SW1A 1AA”, not “Invalid input” or “Error 422”. (WCAG 3.3.3 Error Suggestion, AA.)
• Sits next to the field it’s about, and the field is visually marked.
• Uses plain language. No codes, no blame (“You entered an illegal value”), no jargon (“Regex mismatch”).
• Isn’t color only. Red plus text plus an icon, so people who can’t see red still notice it. (WCAG 1.4.1 Use of Color, A, and 3.3.1 Error Identification, A.)
• Reaches screen reader users. The field is announced as invalid and the message is read out with it. After a failed submit, focus moves to the first invalid field or to an error summaryError summaryA box at the top of a form listing every problem after a failed submit, each linking to its field.Open in glossary → at the top that lists every problem as a link. Each link must move focus to its field.
• Keeps the user’s input. Nothing typed is cleared after an error. Many teams clear the password on purpose; if so, say so and keep everything else.
• Disappears when the problem is fixed, and comes back if it’s broken again.

Server errors need the same care. “Something went wrong” with no next step is a dead end. Better: “We couldn’t create your account right now. Your details are saved, please try again in a minute.” And if the server rejects one field (“This email is already registered”), the message belongs next to that field, not in a generic toast.

Data formats and edge cases

Most “invalid input” bugs are really valid input the developer didn’t expect. Keep these lists handy as test dataTest dataThe input values, accounts and records you use while testing.Open in glossary →.

Names

Two separate fields for first and last name don’t fit every culture. A single Full name field is often simpler. If the spec splits them, test what happens to single names and long double surnames.

Emails

• Plus addressingPlus addressingAdding +something before the @ in an email address, like anna+shop@mail.com. Mail still reaches anna@mail.com.Open in glossary →: anna+groceries@mail.com is valid and widely used to filter mail. Rejecting + is one of the most common form bugs.
• Subdomains and long domains: anna@mail.example.co.uk, anna@company.photography.
• Dots and dashes: anna.maria-k@mail.com.
• Length: the part before @ can have up to 64 characters, and a whole address up to 254 in practice. Test a long but valid one.
• Case and spaces: Anna@Mail.com and a trailing space from autofill should be cleaned up, not rejected.
• Typos: anna@gmial.com is valid but wrong. Some apps suggest “Did you mean gmail.com?”. Nice to have, not a validation rule.

Phone numbers

People type phone numbers the way they see them: +44 7700 900123, +385 (91) 234-5678, 0049 151 1234567. The international format (E.164) has up to 15 digits after the +. A good form accepts spaces, dashes and brackets, removes them before saving, and either asks for the country or offers a country code picker. Test with numbers from every market the product serves, and never rely on a 10-digit limit.

Postcodes by country

The postcode rule must depend on the selected country, and changing the country should re-check the postcode. A leading zero (01067) is a classic: if the field is stored as a number, it becomes 1067.

Dates and ages

• The birthday boundary: with an 18+ rule, someone whose 18th birthday is today is allowed. Test the day before, the day itself and the day after. This is boundary value analysisBoundary value analysisTesting values at and just around the edges of valid ranges, where bugs love to hide.Open in glossary →, and the classic bug here is an off-by-one errorOff-by-one errorA bug where a count or boundary is wrong by exactly one, like counting days instead of nights.Open in glossary →.
• 29 February: when does someone born on 29 February 2008 turn 18 in a non-leap year? The answer depends on the country’s law. Ask, then test it.
• Impossible dates: 31 2 1995 should be rejected with a message, not silently become 3 March (see Date Picker).
• Day and month order: 03/04/2005 is 3 April in Europe and March 4 in the US. Separate Day, Month and Year boxes, or a date picker, avoid the confusion.
• Future and unrealistic dates: born in 2090 or in 1850.

Numbers, decimals and amounts

1,5 is one and a half in Germany, Croatia and much of Europe; 1.5 in the US and UK. In an amount field, 1,500 can mean fifteen hundred or one and a half. Test with the device set to different regions (see Localization and RTL), and check that 0, negative numbers, very large numbers and leading zeros are handled as the spec says.

Spaces, paste, emoji and formatted text

• Leading and trailing spaces should be trimmed before validating and saving. Spaces inside a password are part of it and must be kept.
• Spaces only in a required field should count as empty.
• Paste must work everywhere, including password and “confirm” fields. Paste a value with a line break at the end (it happens when copying from emails and PDFs).
• Formatted text from Word, a PDF or a website can bring curly quotes (’ instead of '), non-breaking spaces and invisible characters. O’Brien with a curly apostrophe must work too.
• Emoji in names, notes and addresses: accepted or rejected with a clear message, never stored as ???.
• Length limits on paste: if a field has a maximum, pasting a longer value shouldn’t cut it silently (see truncationTruncationText that gets cut off because it doesn't fit its space.Open in glossary →).

Multi-step forms, double submit and server errors

Multi-step forms and saving progress

Long forms (insurance quotes, loan applications, checkouts) are often split into steps, a wizardWizardA long task split into ordered steps with a progress indicator, like a checkout.Open in glossary →. Test that Back keeps what was entered, that you can’t skip a required step, that the step indicator is right, and that a draft survives a refresh or a closed app if the spec promises it. The Wizard page has a full bug hunt on this. For long forms, ask whether progress is saved on the server or only on this device: a draft that exists only on the phone is gone when the user switches to the laptop.

Preventing double submit

A slow network, an impatient user, and a button that stays active: that’s a double submitDouble submitA bug where an action runs twice because the user tapped or clicked twice quickly.Open in glossary →, and it creates two accounts, two bookings or two support tickets. The fix has two layers. The app disables the button and shows a loading state as soon as it’s pressed (and pressing Enter again must not send another request either). The server recognizes a repeated request, for example with an idempotency key (see idempotencyIdempotencyAn action that gives the same result no matter how many times it is repeated.Open in glossary →). Test with the network throttled: tap twice, press Enter twice, tap and press Enter.

Server errors and lost connections

What happens when the server answers 500, or the connection drops after you tap Submit? The user should see a clear message, all their input should still be there, and they should be able to try again without creating a duplicate. Test it by turning on airplane mode right after submitting, or with a proxy tool that returns an error. On the web, a broken form that wipes everything after an error is one of the most frustrating bugs a user can meet.

Session timeout during a long form

Users fill in long forms slowly: they look up their passport number, answer the door, come back an hour later. If the sessionSessionThe period during which a user stays logged in without entering their credentials again.Open in glossary → expired meanwhile, the submit fails. Good behavior: warn before the session ends and let the user extend it (WCAG 2.2.1 Timing Adjustable, A), or after logging in again, return to the form with the data still there. Bad behavior: a login screen, and then an empty form. Test it by leaving a filled form open past the timeout, or ask a developer for a build with a 1-minute timeout.

The browser Back button and refresh

• Back after submit: going back to a submitted payment or sign up form and submitting again must not create a second order or account.
• Refresh on the result page: if the result page was the direct answer to a POST, the browser asks “Confirm form resubmission”. Good sites redirect after a successful submit, so a refresh is harmless.
• Back from the next page to fix something: the form should still be filled in, not empty.

Security and privacy basics

• No personal or secret data in URLs. A form sent with GET puts every field in the address as query parametersQuery parameterData in a URL after the ?, like ?q=mug&sort=price, often used to keep search and filter state.Open in glossary → (?email=…&phone=…). URLs end up in browser history, server logs, analytics and shared links. Check the Network tab in DevToolsDevToolsDeveloper tools built into browsers for inspecting pages, network traffic and errors.Open in glossary →: forms with personal data should use POST.
• Password fields are masked, have show/hide, allow paste and work with password managers. Details on the Password Field page.
• Rate limiting on sign up. Without it, a script can create thousands of fake accounts or flood people’s inboxes with confirmation emails. Check for rate limitingRate limitingCapping how many requests a user or device can make in a period of time.Open in glossary →, a CAPTCHA or email verification, and that the limit is enforced on the server.
• Consent is opt-in. Marketing checkboxes start unticked (required under GDPR in the EU), and the Terms checkbox is actually enforced, on the server too. See Checkbox.
• Input is stored as text, not run as code. Try <b>Anna</b> in a name and check every place it’s shown later (see Security basics).
• Only collect what’s needed. A newsletter sign up that asks for a date of birth and phone number is a privacy question worth raising.

Accessibility checklist for forms

Forms are where accessibility problems hurt most: if someone can’t submit, they can’t buy, book or sign up at all. Use this list together with Accessibility basics:

On mobile, run the same checks with VoiceOver and TalkBack (screen readersScreen readerSoftware that reads the screen aloud for blind and low-vision users, like VoiceOver or TalkBack.Open in glossary →): every field should announce its label, type, value, hint and error.

What usually goes wrong

Test scenarios

Functional

• Sign up with all valid data; the account is created and every value is saved exactly as entered (after trimming).
• Optional fields can be left empty; required fields can’t.
• The confirmation email arrives, and the new account can log in.
• Changing the country updates the postcode rules and re-checks the postcode.
• AutoFill and password managers fill every field correctly.

Negative

• Submit the empty form: every required field gets a message and the summary lists them all.
• Spaces only in required fields.
• Invalid formats: anna@, anna@@mail.com, 12abc as a phone number, SW1A as a UK postcode.
• Underage date of birth, impossible date (31 2 1995), a date in the future.
• Email already registered (the message follows the spec and doesn’t reveal more than intended).
• Terms not accepted.

Edge cases

• Names: O'Brien, O’Brien (curly apostrophe), Đorđe, Anne-Marie, a single name, 100 and 101 characters.
• Emails: plus address, subdomain, 64-character local part, uppercase.
• Phone: with spaces, dashes and brackets, with 00 instead of +.
• Postcodes for every supported country, including a leading zero.
• Date of birth: exactly 18 today, 18 tomorrow, 29 February.
• Pasting values with a trailing line break or non-breaking space; emoji in the street name.
• Decimal comma vs point in numeric fields, with the device set to a different region.

Whole-form behavior

• Double tap and double Enter on submit with a slow network: one account.
• Server returns 500, 422 or times out: clear message, input kept, retry works.
• Connection lost right after submitting.
• Session expires while the form is open.
• Back after a successful submit, refresh on the result page, Back to fix a value.
• App sent to the background and reopened halfway (see Background and foreground).

Server-side

• Send the request without the app, with each client rule broken: too long, wrong format, missing required field, extra unknown fields.
• Check that the server trims and normalizes values the same way the app does.
• Many sign ups from one device or IP: rate limit or CAPTCHA kicks in.

UI and accessibility

• Labels, help text, optional markers and grouping are consistent.
• The right keyboard opens for each field on iOS and Android.
• The focused field and its error are not hidden behind the keyboard.
• Everything from the accessibility checklist above.

Example test cases

Mobile vs web