Forms Validation With Native HTML (No JavaScript Needed)

Back in the forms lesson, you briefly saw required prevent a form from submitting when a field was left empty. This lesson goes deeper into HTML's built-in validation system, which can catch a surprising number of common input mistakes before any JavaScript ever runs.

Required Fields

The required attribute is the foundation. Add it to any input that must not be left empty:

<label for="contact-name">Name</label>
<input type="text" id="contact-name" name="contact-name" required>

Try submitting a form with this field empty, and the browser blocks submission entirely, showing a small built-in message like "Please fill out this field," pointing directly at the empty input. No JavaScript, no server round-trip, nothing beyond this one attribute.

Type-Based Validation

The type attribute itself contributes real validation too, not just keyboard hints as mentioned earlier in this course. type="email" checks for a basic valid email shape, something@something, before allowing submission:

<input type="email" id="contact-email" name="contact-email" required>

Typing "tonystark" without an @ symbol and domain triggers a built-in warning; typing "tony@starkindustries.com" passes. This isn't a full, airtight email validity check, a determined user could still enter a fake-but-correctly-shaped address, but it does catch simple typos and clearly wrong input for free.

Numeric And Length Limits

For numeric constraints, min and max work with type="number":

<label for="suit-count">Number of Suits Owned</label>
<input type="number" id="suit-count" name="suit-count" min="0" max="100" required>

This prevents submitting a negative number or something absurdly large, and most browsers also show small up and down arrows for convenient incrementing.

For text length, minlength and maxlength constrain how many characters are acceptable:

<label for="message">Message</label>
<textarea id="message" name="message" minlength="10" maxlength="500" required></textarea>

A visitor typing fewer than 10 characters gets blocked on submit with a native warning; maxlength actually prevents typing beyond 500 characters at all, rather than just warning afterward.

Pattern Matching With Regex

Here's a genuinely powerful but underused attribute: pattern, which uses a regular expression to validate exact formatting.

<label for="suit-code">Suit Model Code</label>
<input type="text" id="suit-code" name="suit-code" pattern="MK-[0-9]{1,3}" title="Format: MK- followed by 1 to 3 digits, e.g. MK-50" required>

This pattern only accepts input matching "MK-" followed by one to three digits, like "MK-50" or "MK-1". Anything else, "mark50" or "MK50" without the hyphen, gets blocked on submit. Notice the title attribute here isn't just a tooltip for style, most browsers actually display that exact title text as part of the validation error message when the pattern fails, so write it as a clear, genuinely helpful format hint, not just a vague label.

Regular expressions are their own topic well beyond this course, so don't worry about mastering pattern syntax deeply right now; just know this tool exists for when you need exact format enforcement, like phone numbers or product codes with a fixed shape.

Limits Of Native Validation

You can style how invalid and valid fields look using CSS pseudo-classes, :invalid and :valid, though that's a CSS topic outside this course's scope. What you can control directly in HTML is turning off validation entirely when you genuinely need to, using novalidate on the form itself:

<form novalidate>
  <input type="email" id="newsletter-email" name="newsletter-email">
</form>

This is occasionally useful if you're deliberately handling all validation yourself with JavaScript and don't want the browser's built-in messages interfering or appearing inconsistently across browsers with your custom ones. As a beginner, you generally want native validation active, not disabled, so use novalidate sparingly and deliberately.

A common misunderstanding worth clearing up directly: native HTML validation happens entirely in the visitor's browser, which means a technically savvy visitor can bypass it completely, through browser developer tools or by crafting a request manually. This is not a security feature. It's a user experience feature, catching honest mistakes early with zero server round-trip, not a defense against a determined bad actor. Any data that matters for security or correctness must always be validated again on the server, which is outside HTML's job entirely and belongs to whatever backend technology processes the submission.

A practical tip: combine several constraints on one field when it genuinely makes sense, since they all stack together rather than conflicting:

<input type="email" id="contact-email" name="contact-email" required maxlength="100">

Put this into practice: take the contact form you built back in the forms lesson and add required to every field that shouldn't be empty, type="email" validation on the email field, and a pattern with a helpful title on at least one field with a specific expected format, like a phone number or a product code. Try submitting it with each field broken one at a time and read the native browser messages that appear.