Customizing Validation Messages and Attributes in Laravel

When someone submits invalid data through a Laravel form, Laravel displays validation messages that explain what to fix. You can customize the message text and the field name Laravel displays. A custom field name changes “The profile.first_name field is required” to “The first name field is required,” while a custom message replaces the sentence with “Please enter your first name.”

You can define these changes beside a validator, the object that checks submitted data, in a Form Request, or in a validation language file. Laravel picks a message for the failed validation rule, the check that failed, and fills in placeholders such as :attribute. Choosing the right location and wording keeps feedback consistent without exposing internal field names.

Where to define messages and field names

To create a validator yourself, pass custom messages as the third argument to Validator::make and custom field names as the fourth:

$validator = Validator::make(
    $data,
    [
        'email' => ['required', 'email'],
    ],
    [
        'email.required' => 'Please enter your email address.',
    ],
    [
        'email' => 'email address',
    ],
);

The key email.required limits the custom message to the required rule for the email field. This field-name mapping gives messages that use :attribute a readable label. Laravel documents these validator arguments.

For validation tied to one kind of request, define messages() and attributes() on a Form Request, a Laravel class for handling that request. Laravel passes the returned arrays to the validator it builds by default, as shown in the Form Request implementation.

public function messages(): array
{
    return [
        'email.required' => 'Please enter your email address.',
    ];
}

public function attributes(): array
{
    return [
        'email' => 'email address',
    ];
}

Use a Form Request when the wording belongs to one request’s validation rules. Use a language file when messages or field labels should be reused or translated across the application.

Laravel stores translated validation text in language files. For English, the documented file is lang/en/validation.php. If your project does not have a lang directory, run php artisan lang:publish to publish the language files. The custom array stores messages for a specific field and validation rule. The attributes array gives field keys readable display names. The validation documentation describes both structures.

 'The :attribute field is required.',

    'custom' => [
        'email' => [
            'required' => 'Please enter your email address.',
        ],
    ],

    'attributes' => [
        'email' => 'email address',
        'profile.first_name' => 'first name',
    ],
];

The email.required entry overrides the general required wording for that field and rule. The attributes mapping changes the label in messages that contain :attribute; it does not rewrite the sentence itself.

How Laravel chooses a message

Laravel looks for a message for the field and validation check that failed. If it finds none, it uses a more general message. In Laravel 13, the lookup starts with messages supplied to the validator. Laravel checks messages for a specific field and rule before messages for a rule across all fields. It also supports wildcard matches for repeated fields, such as users.*.email. Next, Laravel checks the language file’s custom messages. For size rules such as min, max, and size, it chooses wording based on whether the value is a string, number, or file. Then it looks for the general translated message for the rule. If no translation exists, Laravel checks its fallback messages. The Laravel 13 message-formatting code implements these lookups.

After Laravel selects a message, it fills in the placeholders. For :attribute, Laravel first uses a custom field name supplied to the validator or Form Request. If none is supplied, it checks for a translated field name. If neither provides a label, Laravel generally derives a readable name from the field key, such as replacing underscores with spaces.

For fields repeated across items, one wildcard key lets a custom message cover each matching item:

'users.*.email.required' => 'Enter an email address for each user.',

Make sure the rule and field pattern match the data Laravel checks. Laravel’s validation documentation covers custom messages for array fields.

The lookup details above describe Laravel 13’s implementation. Check the documentation and framework source for the Laravel version installed in your project if you rely on a specific lookup behavior. Laravel 11 documents the same main customization options, including Form Request methods and language-file entries, in its validation documentation.

Keep the wording useful to the person submitting the form

Use the same labels as the form. A label such as first name is easier to understand than an internal key such as profile.first_name. For a general rule message, a field-name mapping may be enough. If the standard message does not tell the person what to do, customize the full message.

For example, “The email address field is required” names the missing field. “Please enter your email address” gives a direct next action. Use consistent wording for similar errors across forms and languages. Avoid showing database terms or internal rule names. For repeated fields, write wording that helps identify which item needs attention when the interface provides that context.

Laravel’s localization system uses language files to store translated text. Put validation messages and field labels in the language files your application supports so translated forms display errors in the same language.

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