Native HTML form validation: required, pattern, type and the Constraint Validation API

What it is

HTML checks form controls before a form is submitted, without any script. required, minlength and maxlength, min, max and step, pattern, and the input types email, url, number and date each declare a constraint. When a control violates one, the browser refuses to submit and shows its own message at the first invalid control. The MDN guide describes the CSS side: an invalid control matches :invalid, and once the user has interacted with it also :user-invalid. The Constraint Validation API (checkValidity(), reportValidity(), setCustomValidity(), the validity object) exposes the same state to scripts; novalidate on the form switches off the browser's bubbles but keeps the API working.

Why it matters

Native validation works before any JavaScript has arrived, executed or failed; its messages appear in the browser's own language with no translation work; and the constraints live once, in the markup, where scripts, tests and crawlers can read them. It is not a security measure: the MDN guide is explicit that the server must validate every submission regardless.

How to apply

• Choose the type first: email, url and number bring their own constraint and keyboard. Use inputmode for free text that only needs a numeric keyboard.
• Add required, minlength, min/max and pattern for format rules. The pattern is compiled as a JavaScript regular expression and must match the whole value. Describe the expected format in visible text and in a title attribute; the cited page notes browsers may use the title in the validation message.
• Style :user-invalid rather than :invalid, so empty required fields are not marked red before the user has touched them.
• Use setCustomValidity() for cross-field rules such as password confirmation, and reset it with an empty string, otherwise the control stays invalid.
• If you render your own error list under novalidate, still call reportValidity() so keyboard and screen-reader users are taken to the first error.
• Test the server path by submitting with novalidate or with curl; the browser's checks are a courtesy, not a contract.

Pitfalls

Native error bubbles cannot be styled, disappear when focus moves and show one error at a time. A pattern on type="email" combines with the built-in check, so both must pass. Disabled controls are never validated. A required control hidden with display: none still blocks submission, but the browser has nowhere to show the message, which is commonly reported as a "form does nothing" bug. Date and number inputs render locale-dependent widgets that are hard to restyle.