Validating Array Inputs with Laravel Wildcards

When a Laravel request contains repeated fields, such as several users with separate email addresses, you can validate each field with one wildcard rule. A wildcard is the * character in a field path, where periods separate nested field names. In users.*.email, it stands for each position in the users array.

Laravel expands the wildcard using the submitted data, then validates each matching field separately. If an email fails, the error is attached to its specific path, such as users.0.email. The field paths let you validate the array and its contents, then match each error to the corresponding form field or API input.

How Laravel matches wildcard rules

Use a rule without * to validate the array itself, and a wildcard rule to validate fields inside its entries:

$request->validate([
    'users' => ['required', 'array'],
    'users.*.email' => ['required', 'email'],
]);

The users rule checks that the request includes users and that its value is an array. The users.*.email rule applies required and email to the email field at each matching position, such as users.0.email and users.1.email. Laravel documents this pattern for validating nested array fields.

Laravel uses the submitted structure to turn the wildcard rule into specific field paths. Its rule parser also records which paths came from the wildcard rule. You write one rule, and Laravel applies it to each matching entry.

You can use more than one wildcard for deeper arrays. For example, photos.*.attributes.*.name targets each name field inside each photo’s attributes array. Validate the parent arrays separately when you need to require them or check that they have the expected structure.

A wildcard rule checks the fields it describes; it does not, by itself, restrict every key that an array may contain. When only certain keys should be accepted, specify the allowed keys in the parent array rule, as Laravel recommends in its array validation documentation.

Where Laravel attaches validation errors

Laravel assigns each validation error to the field path that failed. If the second user’s email is invalid, the error key is users.1.email, rather than the literal rule pattern users.*.email. Laravel’s JSON validation examples use these paths to identify nested errors.

For a JSON request that expects validation errors, Laravel returns a 422 response with an errors object keyed by the failing fields. For a traditional form submission, Laravel redirects back and makes the errors available to the view. The response depends on the request context; validation failures do not all arrive as JSON.

A custom message can use the wildcard pattern to cover every matching field:

$request->validate(
    ['users.*.email' => ['required', 'email']],
    ['users.*.email.required' => 'Enter an email address for user :position.']
);

Laravel supports :index for a zero-based index and :position for a one-based position in wildcard error messages. Laravel uses the placeholders in the message text and keeps the error associated with its concrete path. For example, :position can display “user 2” for the entry at users.1.email.

What I'm building

Delegate tasks. Get software.

Give Vroni a GitHub issue, bug report, spec, or rough idea. It reads the repo, plans the change, writes code, runs checks, and works toward a review-ready pull request.

Take a look at vroni.com