Your form tells real customers their name or email is invalid: loosen the rule, not the standard

Two ways to fail: too loose and too strict

Teams add form rules to stop junk and bad data, and each new rule risks turning away a customer. The failure is easy to miss because a rejected person simply leaves; nothing appears in a log unless you record rejections. Before changing a rule, find out whether it is rejecting real people. Keep the rejected values in an internal log for a short time, with personal details handled according to your own privacy rules, and read them.

• Ask support whether anyone has said the form would not accept their details.
• Look at rejected values that came with a long, otherwise sensible message.
• Compare browser-side and server-side rules: the stricter one decides.

Names are less regular than most rules assume

The W3C describes the range: some people have a single name, others have two family names or several given names, many names are not written in the Latin alphabet, and some are long. Its practical advice is to consider one full-name field, to allow long input, not to force a family name, to be lenient and to warn rather than block, and not to assume that a single-letter name is an initial. It also notes that a four-character Japanese name can need about 12 bytes in UTF-8, so a tight database column can silently truncate or reject it. OWASP makes the related point that blocking apostrophes rejects real names without making any query safe.

• Allow letters from any script, spaces, hyphens, apostrophes and full stops.
• Do not require a minimum of two words or a family name.
• Check database column sizes in bytes, not characters.
• Protect queries with parameterised statements, not by stripping punctuation.

Email addresses and what format checks can prove

A reasonable address check is simple. The HTML Standard defines a practical valid email address, whose local part accepts a plus sign and other punctuation, and openly describes its rule as a willful violation of the full RFC 5322 grammar because that grammar is impractical for forms. MDN notes that type="email" already validates a format without a custom pattern. A home-made pattern that rejects the plus sign rejects a common way people file their own mail. And no format rule proves the address is reachable or belongs to the person; OWASP states that format validation does not prove mailbox access. If ownership matters, send a confirmation message rather than tighten the pattern.

• Accept plus signs and subdomains in addresses.
• Do not reject on top-level domain lists you have to maintain.
• Use a confirmation email, not a stricter pattern, to prove ownership.

Messages and a test set that stays

When a rule does reject something, say in text which field and why, and keep what the person typed. MDN notes that native browser messages follow the browser's language and cannot be styled, so some sites replace them with their own. Then build a genuine test set that must always pass: a name with an accent, one with an apostrophe, a single-word name, a long name, an address with a plus sign and a message with unusual punctuation. Run it against both the browser rules and the server rules whenever either changes.

• Keep the set in the tests so a later change cannot silently reject them.
• Add any real value that was ever wrongly rejected, with personal details removed.

How the paid job is accepted

This is one half of our form job (posted test price £245, untested, paid only after sign-off): the genuine test set must all be accepted while an agreed junk set is rejected by the server. We review and loosen browser-side rules that turn away real people, and show messages in text that name the field. The job does not cover email delivery, other forms or any outside service account. Send an anonymised example of a value that was wrongly refused and the form description in your first enquiry, not customer submissions.