HTML validation can catch common mistakes before a form leaves the browser. It improves feedback, but it cannot secure an endpoint because a request can bypass the page entirely.
Express simple rules in HTML
Choose a meaningful input type and add required, minlength, maxlength, min, max or pattern only when the rule is real and explainable. Do not make a field required merely because the interface allows it.
<label for="email">Email address</label>
<input id="email" name="email" type="email" autocomplete="email" required>
<label for="message">Message</label>
<textarea id="message" name="message" minlength="20" maxlength="2000" required></textarea>Use the Constraint Validation API sparingly
For a rule involving more than one field, check validity and set a specific message with setCustomValidity. Clear the custom message as soon as the value becomes valid so the visitor can submit again.
Validate again at the destination
Treat every received value as untrusted. The endpoint must enforce allowed types, lengths and business rules even when the exported page already validates them. Client validation is user guidance, not an authorization or security boundary.
Test invalid and corrected states
Try empty required fields, malformed addresses, boundary lengths and unexpected Unicode. Confirm the form identifies the problem, preserves unrelated values and accepts the corrected input.
Frequently asked questions
Can I validate a form without JavaScript?
Yes. Native input types and constraint attributes cover many common rules.
Why repeat validation on the server?
Attackers and custom clients can send requests without using the HTML page, so the receiving system must enforce its own rules.
Should I use a complex pattern for email?
Usually no. The email input type provides a browser-level format check; the destination can apply any additional product-specific rule.
Primary sources
Turn the guide into a working form
Start from a template, change the fields and take the code with you.
Open the free builder