HTML pattern: validate a field's syntax without claiming identity

Use it in a concrete workflow

A depot asks for a local six-character claim reference: two uppercase letters followed by four digits. The visible label and description give users the rule; the pattern mirrors it as a client-side check. A syntactically valid reference can still be nonexistent, belong to another account, or be expired. The server must verify those facts and repeat the syntax check, because clients can bypass or change their own markup.

<form action="/claims/lookup" method="get">
  <label for="claim-reference">Claim reference, two letters and four digits</label>
  <input id="claim-reference" name="reference" type="text" pattern="[A-Z]{2}[0-9]{4}" title="Use two capital letters followed by four digits" required>
  <button type="submit">Find claim</button>
</form>

Behavior and ownership

The expression describes the whole value under HTML pattern matching. It does not normalize lowercase text or remove pasted spaces; decide whether the product should transform input before checking it.

Performance and maintenance

Browser matching is cheap for this bounded expression. Complicated patterns cost authoring and testing time, can yield poor error messages, and still do not replace server-side record lookup.

Common Mistakes

• Do not use a successful pattern match as authorization.
• Do not place the only rule explanation in title.
• Do not write an expression whose accepted values differ from server policy.

Connected lessons

• HTML constraint validation: improve feedback without trusting the browser
• HTML labels: bind each control to a durable accessible name
• HTML character references: escape data before inserting it into markup