Default validation rules

DomValidation ships with a default set of rules that are based on common HTML form constraints.

This is an important point: the library does not try to implement every possible piece of browser form validation. It implements a practical subset that maps cleanly onto the current codebase.

If we need more than that, we can extend the library with our own rules, which we will cover later in Extending custom rules.

Required fields

• required

If a field marked required is empty, validation fails.

The exact message depends on the kind of control:

• ordinary inputs: This field is required
• required <select> elements: Please select an item in the list
• required radio groups: Please select one of these options

Example:

<label>
	<span>Your name</span>
	<input name="name" required />
</label>

Text length

• minlength
• maxlength

These rules apply to the number of characters in a submitted value.

Example:

<label>
	<span>New password</span>
	<input name="password" type="password" minlength="12" maxlength="128" />
</label>

If the value is too short, the hint is:

This field's value must contain at least 12 characters

If the value is too long, the hint is:

This field's value must contain 128 characters or less

Pattern matching

• pattern

The pattern attribute is compiled as a regular expression with the u flag, so it is treated as Unicode-aware.

Example:

<label>
	<span>Username</span>
	<input name="username" pattern="\w{3,16}" />
</label>

If the pattern does not match, the default hint is:

This field does not match the required pattern

If the element also has a title attribute, that text is appended to the hint. This is a good way to explain the rule in human language:

<input
	name="pin"
	type="password"
	pattern="\d{4}"
	title="Use exactly four digits"
/>

Resulting hint:

This field does not match the required pattern: Use exactly four digits

Input types

The following type values are validated by the built-in rules:

• email
• url
• date
• month
• week
• time
• datetime-local
• number
• range

Email and URL

email and url are validated using PHP's filter functions.

<input name="email" type="email" />
<input name="website" type="url" />

Date and time formats

These types are validated against specific formats:

Input type	Expected format	Example
date	Y-m-d	2026-05-07
month	Y-m	2026-05
week	Y-\WW	2026-W19
time	H:i	14:30
datetime-local	Y-m-d\TH:i	2026-05-07T14:30

For week, the week number must currently be between 1 and 52.

Number and range

number and range support:

• numeric value checking
• min
• max
• step

Example:

<input name="amount" type="number" min="0" max="100" step="5" />

If the value is not numeric, the hint is:

Field must be a number

If it is outside the allowed range, the hint explains whether it is too low or too high. If the step is wrong, the hint explains whether the value should be a multiple of the step or a value offset from min.

Available option checking

DomValidation also validates whether submitted values actually exist in the form markup for three common cases.

<select>

For <select> elements, submitted values must match one of the available option values.

<select name="currency" required>
	<option></option>
	<option value="GBP">Pound sterling</option>
	<option value="EUR">Euro</option>
</select>

Radio groups

For radio inputs, the submitted value must match one of the radio buttons in the same form with the same name.

<input type="radio" name="sort" value="asc" />
<input type="radio" name="sort" value="desc" />

Checkbox groups

For checkbox groups, every submitted value must match one of the available checkboxes.

<input type="checkbox" name="interest[]" value="php" />
<input type="checkbox" name="interest[]" value="css" />
<input type="checkbox" name="interest[]" value="sql" />

If a submitted value is not one of the available choices, the hint is:

This field's value must match one of the available options

What is not covered by default

A few examples of things that are not separate built-in rules in the current library:

• type="tel" format validation
• type="color" validation
• browser-specific constraint validation behaviour outside the implemented rules
• cross-field rules such as "confirm password must match password"
• domain-specific rules such as username uniqueness

Those are exactly the kinds of things custom rules are for. If you want to request that a rule becomes part of the standard set, please raise an issue on GitHub.

---

Next, move on to Enforcing validation on user input to see how these rules are triggered in PHP.