Conditional Validation in Laravel Using When and Prohibited If

Laravel lets you choose different validation rules for request fields based on other submitted values. It can also require a field to be missing or empty under a specific condition. A validation rule is a check Laravel applies to submitted input, such as requiring a field or limiting its value to a string.

Use Rule::when to choose rules based on input. Use prohibited_if when a field must be missing or empty under a specific condition. prohibited_if does not require the field when its condition is false. The examples use Laravel 12.x behavior.

Use Rule::when to switch a field’s rules

When the condition is true, Rule::when applies one set of rules; when it is false, it can apply an optional default set. The callback receives the submitted input as an Illuminate\Support\Fluent object, so it can read another field's value. Laravel documents the conditional rule API and handles the rule selection in its conditional rules class.

For example, a payment request can require a card number for card payments and prohibit that field for cash payments:

use Illuminate\Support\Fluent;
use Illuminate\Validation\Rule;

$rules = [
    'payment_type' => ['required', Rule::in(['card', 'cash'])],

    'card_number' => [
        Rule::when(
            fn (Fluent $input) => $input->payment_type === 'card',
            ['required', 'string'],
            ['prohibited'],
        ),
    ],
];

$request->validate($rules);

When payment_type is card, Laravel applies required|string to card_number. When it is cash, Laravel applies prohibited. If the endpoint needs to validate card-number format, add format-specific checks; string alone checks only the value’s type.

The third argument gives the rules Laravel applies when the condition is false. If you omit it, that Rule::when expression adds no rules for the false condition. Also validate the field that controls the condition, as the example does with required and Rule::in.

Use prohibited_if to reject a value in one branch

When you need to compare one input field with a specific value in another, prohibited_if:field,value gives you a shorter rule:

$rules = [
    'payment_type' => ['required', Rule::in(['card', 'cash'])],
    'card_number' => ['prohibited_if:payment_type,cash'],
];

When payment_type is cash, Laravel rejects card_number if it has a value. The field passes this check when it is missing or empty. Under the prohibited validation rules, Laravel treats null, an empty string, and an empty array as empty. It also treats an empty Countable object and an uploaded file with an empty path as empty.

This rule does not require card_number when payment_type is card. Add a complementary conditional requirement, such as Rule::when, when the other branch needs the field to be present.

Use Rule::prohibitedIf when a condition depends on PHP logic rather than a simple input comparison. It accepts a boolean or a zero-argument closure, meaning true or false, or a function that takes no arguments. For example, an endpoint can prohibit a submitted role value when the authenticated user is an administrator:

use Illuminate\Validation\Rule;

$rules = [
    'role_id' => [
        Rule::prohibitedIf(fn () => $request->user()->is_admin),
    ],
];

If the closure returns true, Laravel applies the prohibited rule. If it returns false, Laravel adds no prohibition. The Laravel 12.x implementation shows how the return value controls the rule. Authenticate the request before relying on $request->user().

Keep conditional rules separate from sometimes

Laravel uses “sometimes” in two related ways. As a validation rule, sometimes tells Laravel to validate a field only if it appears in the submitted input. The validator method $validator->sometimes(...) adds rules to fields when its callback returns true. Laravel documents that method for adding rules to one or more fields based on input.

Use Rule::when in a field’s rule declaration to choose between rule sets for that field. Use $validator->sometimes(...) to add rules to named fields after you create a validator. These uses do not change what prohibited_if does: it still checks whether a field has a nonempty value under its stated condition.

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