HTML constraint validation: improve feedback without trusting the browser

Use it for a real task

A receipt address field asks for an email-shaped value and a note of bounded length. The browser can prompt users early. The backend must repeat every relevant validation rule because callers can send HTTP requests without using this form or can modify its markup.

<form action="/receipts/notify" method="post">
  <label for="recipient-email">Recipient email</label>
  <input id="recipient-email" name="email" type="email" required>
  <label for="review-reason">Review reason</label>
  <input id="review-reason" name="reason" type="text"
         minlength="8" maxlength="120" required>
  <button type="submit">Queue notice</button>
</form>

What the markup guarantees

Client validation does not prove the mailbox exists or the sender may contact it. Error messages, focus order, and server rejection still need design. A length limit here counts form-control input according to browser rules, not necessarily the backend's storage bytes.

Cost and limits

Native checks avoid an extra JavaScript dependency for basic cases. Complex custom validation increases code and can reduce accessibility if errors are not tied to their fields.

Common Mistakes

Do not treat required as a server-side security rule.
An email input checks syntax, not delivery.
Avoid removing native validation unless a replacement supplies comparable feedback.

Connected lessons

Continue with HTML input types: choose controls from the value contract.

Continue with HTML progress, meter, and output: three different value relationships.

Apply this in HTML form error project: return values, summary links, and field repairs.

Continue with HTML number boundaries: align min, max, and step with the real unit.

Related CSS decisions

CSS :user-valid: confirm a checked field without premature praise

Continue with the connected Web Development lesson: Form submission: validate on the server and return field errors.