Laravel validation rule builder

Pick fields and field types and get a complete FormRequest class with array-syntax validation rules you can paste straight into a Laravel app.

About the laravel validation rule builder

Validation rules written inline in a controller are the usual reason request handling becomes untestable. This builder takes a list of fields and their types and produces a complete FormRequest class with array-syntax rules ready to paste into the application.

Array syntax is used deliberately: it is easier to read, easier to extend with rule objects, and does not break when a rule contains a pipe character.

When to use it

  • You are adding an endpoint and want validation in a FormRequest from the start.
  • You are refactoring inline validation out of a controller.
  • You want consistent rules for common field types across a codebase.
  • You are documenting the shape of a request payload.

What it does not do

  • It does not generate custom rule objects or database-aware rules tuned to your schema.
  • It does not write authorisation logic beyond the method stub.
  • It cannot know your business constraints — extend the generated rules.

How the result is produced

Each field type maps to a sensible base rule set, then required or nullable and any extra rules you add are appended. The output is a complete class with the correct namespace, an authorize stub and a rules method.

What to watch out for

Validation belongs at the boundary of the application, before a controller has to think about the shape of the input. Moving rules into a form request class gives you one place to read what an endpoint accepts, a natural home for authorisation, and something you can test without exercising the controller at all.

Be specific with types. A field validated only as a string will happily accept an eight-thousand-character payload; adding a maximum length, a format rule and a range where relevant turns validation into an actual contract rather than a formality.

The generated class is a starting point. Business constraints — uniqueness scoped to a tenant, cross-field conditions, state-dependent requirements — need rules that know your schema, and those are worth writing as rule objects so they can be tested and reused.

Error messages deserve as much attention as the rules themselves. Default messages are accurate and often unhelpful to the person filling in the form, particularly for format rules where the requirement is obvious to you and invisible to them. Overriding messages on the rules most likely to fail, and naming attributes in human terms rather than database column names, removes a surprising amount of support load from a form that is otherwise working exactly as designed.

Real inputs and the exact output

Every example below was run through this laravel validation rule builder and copied verbatim.

The Laravel validation rule builder with field rules selected and the generated FormRequest class on the right
Build rules field by field and copy them as an array or a full FormRequest class.

Example 1: A signup request with a unique email and a strong password

Registration form that also accepts an optional avatar upload.

Array syntax beats pipe strings once a rule contains a regex or a comma — and it is the only form that accepts rule objects like `Password::min()`.

app/Http/Requests/StoreUserRequest.php

<?php

namespace App\Http\Requests;

use Illuminate\Foundation\Http\FormRequest;
use Illuminate\Validation\Rules\Password;

class StoreUserRequest extends FormRequest
{
    public function rules(): array
    {
        return [
            'name'     => ['required', 'string', 'max:120'],
            'email'    => ['required', 'email:rfc,dns', 'unique:users,email'],
            'password' => ['required', 'confirmed', Password::min(12)->mixedCase()->numbers()],
            'avatar'   => ['nullable', 'image', 'mimes:jpg,png,webp', 'max:2048'],
            'terms'    => ['accepted'],
        ];
    }

    public function messages(): array
    {
        return ['terms.accepted' => 'Please accept the terms to continue.'];
    }
}

How it works

  1. Add each request field and choose the type that best describes it.
  2. Mark fields required or nullable and append any extra rules you need.
  3. Copy the generated FormRequest class into `app/Http/Requests`.

Frequently asked questions

Why array syntax instead of pipe-delimited rules?
Array syntax avoids ambiguity when a rule value itself contains a pipe — regular expressions being the common case — and it is the form Laravel's own documentation now favours for anything non-trivial.
Should validation live in a FormRequest or the controller?
A FormRequest, in almost every case. It keeps controllers thin, makes the rules reusable and testable in isolation, and gives you an authorisation hook in the same class.
Is `required` enough to keep bad data out?
No. Validation protects the request; the database should protect the data. Pair rules with matching NOT NULL, unique and foreign key constraints so a bug in one layer cannot corrupt the table.

Want a real number instead of an estimate?

A fixed-price Laravel codebase and architecture audit gives you a written scope, a risk list and a delivery date before you commit to a build.

Related free tools

Laravel migration generator — A free Laravel migration generator and visual schema builder: design a table — columns, types, nullability, indexes, foreign keys — and get a valid migration class with the correct filename.

PHP regex tester — Test a pattern against sample text, see every match and capture group live, and copy the finished `preg_match_all()` call.

Artisan command cheatsheet — A searchable reference of the Artisan commands you actually use — what each one does, when to reach for it, and the flags worth knowing.

All free Dev Loader tools

Every tool below runs entirely in your browser — no account, no upload and no limits. 25 tools in total.