All built-in validation rules — required, string, email, min, max, unique, etc.

Concept

Laravel ships with over sixty built-in validation rules, each implemented as a method on Illuminate\Validation\Validator following the pattern validate{RuleName}($attribute, $value, $parameters, $validator). The rule engine iterates every field-rule pair, resolves the rule to either a method on the Validator class or a callable, executes it, and accumulates failures into the MessageBag.

Rules can be expressed as pipe-delimited strings ('required|string|max:255') or as arrays (['required', 'string', 'max:255']). The array form is preferred when a rule itself contains a pipe — for example a regex rule like Rule::in(['foo|bar']) would be ambiguous in string form. When you pass a Rule object instance in the array, the Validator calls its passes() method.

The table below groups the most important rules by category:

The bail modifier is especially important: by default the Validator runs all rules for a field even after the first failure, collecting every error. Adding bail tells the Validator to stop processing a field's rule list after the first failure. This prevents misleading cascaded errors (e.g., reporting that a value is not a valid URL when the real problem is it was not provided at all).

The confirmed rule is a convenient shorthand: 'password' => 'required|confirmed' expects the request to also contain password_confirmation with an identical value. The framework generates the confirmation field name by appending _confirmation.

The email rule supports driver qualifiers: email:rfc validates to RFC 5322, email:dns checks the domain has an MX record, email:spoof detects homograph attacks with unicode characters. You can chain them: email:rfc,dns,spoof.

Code Example

<?php

use Illuminate\Http\Request;
use Illuminate\Validation\Rule;

// Comprehensive example covering the most important rule categories
$request->validate([
    // Presence + type
    'username'    => ['required', 'string', 'alpha_dash', 'min:3', 'max:30'],

    // Email with RFC + DNS validation
    'email'       => ['required', 'email:rfc,dns'],

    // Numeric range
    'age'         => ['required', 'integer', 'between:18,120'],

    // bail: stop on first failure, so 'email' errors don't cascade
    'website'     => ['bail', 'nullable', 'url', 'max:2048'],

    // confirmed: expects 'password_confirmation' in request
    'password'    => ['required', 'string', 'min:12', 'confirmed'],

    // Date logic
    'starts_at'   => ['required', 'date', 'after_or_equal:today'],
    'ends_at'     => ['required', 'date', 'after:starts_at'],

    // Enum-style membership
    'role'        => ['required', Rule::in(['admin', 'editor', 'viewer'])],

    // Array of known values
    'tags'        => ['nullable', 'array', 'max:5'],
    'tags.*'      => ['string', 'max:50'],

    // Boolean (accepts true/false/1/0/"1"/"0")
    'is_active'   => ['required', 'boolean'],

    // File upload
    'avatar'      => ['nullable', 'image', 'mimes:jpg,png,webp', 'max:2048'], // max in KB
]);

Interview Q&A

Q: What does the bail modifier do, and when is it important to use it?

By default Laravel's Validator runs every rule for a given field and collects all failures. The bail modifier short-circuits rule processing for that field after the first rule fails. This matters for two reasons: it prevents misleading cascaded errors (showing "must be a valid URL" when the field was simply empty), and it avoids unnecessary computation — for example skipping a unique database query when the field didn't even pass a string check. Always add bail when you have expensive rules (database lookups, custom closures) later in a field's rule list.

Q: How does the confirmed rule work under the hood?

The validateConfirmed method in Illuminate\Validation\Validator checks that $data[$attribute . '_confirmation'] exists and is strictly equal to $data[$attribute] using Str::is(). There is no special handling needed on the _confirmation field itself — you only declare the rule on the primary field. This is the same mechanism used for Laravel's built-in password reset and registration forms. Note that _confirmation fields are implicitly excluded from the validated data returned by validated().

Q: What are the differences between nullable, present, filled, and missing?

nullable allows the field value to be null and skips subsequent type/format rules when null is received. present requires the key to exist in the input data but permits any value including null or empty string. filled requires the field to be present and non-empty if it is present, but does not require it to exist at all. missing asserts the field must not be present in the input — useful in API versioning when you want to reject deprecated fields. These four together give you precise control over the presence/absence/emptiness semantics of every input key.