What is a regex pattern in a form field?

How a browser reads a pattern

On a web form, a pattern is added to a text input through the pattern attribute, and MDN spells out the details that trip people up. It applies to text, tel, email, url, password and search inputs. It must match the entire value rather than part of it, as though the expression were wrapped in anchors at the start and the end, so a postcode pattern of four digits will not accept five. It is compiled with the v flag, which makes it Unicode aware. An empty value is not checked at all unless the field is also required, so a pattern alone never forces an answer. When a value fails, the field reports a pattern mismatch and the form will not submit until it is fixed.

Writing patterns people can pass

Start from real answers, not from the specification. Collect twenty genuine examples of the value, including the messy ones, and make sure every one of them passes before worrying about what the pattern rejects. Tidy the input before matching: remove spaces from phone and business numbers, trim the ends, and convert to upper case if that is how the value is stored. Then tell people the format in visible text near the field. MDN warns against relying on the title attribute for this because many browsers and screen readers do not expose it well, and the W3C forms tutorial shows the expected format written straight into the label. A pattern people can see is a pattern people can meet on the first try.

Where patterns cause harm

Some answers should never have a pattern. Names come in every length and script, with apostrophes, spaces and hyphens, and a pattern that allows only letters rejects a surprising share of real people. Street addresses are nearly as varied. Email addresses are the classic trap: a pattern that tries to follow every rule in the standard is unreadable and still wrong, which is why OWASP suggests a basic check and then letting the mail system decide. Badly built patterns are also a security risk. OWASP lists regular expression denial of service among the concerns, where nested repetition makes some inputs take so long to test that a server stalls, and recommends anchoring the whole string rather than using wildcards that match anything.

Patterns belong on the server too

A pattern in the browser is a convenience for the respondent, not a guarantee for the organisation. Anybody can remove the attribute from the page or send data straight to the address the form posts to, so every pattern that matters has to be checked again where the answer is received. OWASP describes this as allowlist validation: define exactly what good input looks like and reject everything else, on the server, using anchored expressions. The server version is also the right place for the checks a pattern cannot do, such as looking up whether a business number is registered or whether an order number exists, which turn a shape check into a real one.

Patterns and this form builder

This form builder has no regex pattern setting. Its Validation settings offer a Required Field switch, minimum and maximum length on short and long text, and minimum and maximum value on number fields, and neither the browser nor the server checks a pattern on any field. The practical substitutes cover most cases. A number field with a range handles quantities and amounts. Equal minimum and maximum lengths catch a postcode typed with three or five characters, although length is only checked when the form is submitted. A dropdown or radio field replaces any answer with a fixed set of values, such as a state. For a business number or an order reference, collect it as short text, as the trade account example does with its ABN, and check it in the system that receives the webhook.

Questions people ask