nullable

Allows null to pass while the field's other rules still apply to any non-null value.

Signature
nullable

Errors

Nothing. It suppresses failures from sibling rules rather than producing any of its own.

The field under validation may be null. It adds no check of its own — it tells the validator to stop and pass the field as soon as the value is null, so the rules sitting beside it never see a null.

Why you need it more often than you expect

Laravel's global middleware stack includes TrimStrings and ConvertEmptyStringsToNull. A form field left blank therefore arrives as null, not "". Without nullable, a rule like date or integer treats that null as a bad value and fails, which is why an optional field on a plain HTML form breaks the moment someone leaves it empty.

nullable is not "optional"

This is the distinction people get wrong. Almost every rule already skips a key that is absent from the payload; nullable only matters once the key is present with a null value. If you want "validate this only when it is sent at all", the rule you want is sometimes.

Never pair it with required

required|nullable is contradictory: required rejects null outright and nothing downstream can undo that. Choose one.

The same applies inside arrays — 'items.*.note' => 'nullable|string' lets individual rows carry a null note.

Example

Example · php
<?php

use Illuminate\Support\Facades\Validator;

$rules = ['publish_at' => ['nullable', 'date']];

var_dump(Validator::make(['publish_at' => null],         $rules)->passes());
var_dump(Validator::make(['publish_at' => '2026-01-31'], $rules)->passes());
var_dump(Validator::make(['publish_at' => 'tomorrowish'], $rules)->passes());

// bool(true)   null is allowed through
// bool(true)   a real date still validates normally
// bool(false)  a non-null value is still checked

When to use it

  • Letting a publish_at date be left blank on a draft post while still validating real dates.
  • Accepting an optional phone number that must be well-formed when supplied.
  • Allowing a nullable foreign key such as parent_id that must exist when it is not null.
  • Permitting blank notes on individual rows of a repeating line-item form.

Frequently asked questions

Do I need nullable if the field is simply optional?

Only if the key can be present with a null value. A key that is missing entirely is already skipped by rules like `string`, `integer` and `date`. Because Laravel's ConvertEmptyStringsToNull middleware turns blank form inputs into null, HTML form fields almost always need it; JSON APIs that omit the key do not.

Can I use required and nullable together?

No — they contradict each other and `required` wins, so the field still rejects null. If a field is required in some situations only, use `required_if`, `required_unless` or `Rule::requiredIf()` instead of trying to soften `required` with `nullable`.

Does nullable allow an empty string?

Not by itself — it only exempts an actual null. In a normal Laravel HTTP request that rarely matters, since ConvertEmptyStringsToNull has already turned "" into null before validation. When you build a Validator by hand from raw data, an empty string is still passed to the other rules.

More examples

The same rules with and without nullable

This is the bug report people file: "my optional date field fails when it's empty". The `date` rule is not implicit, but it does run against a present-but-null value and rejects it. `nullable` is what short-circuits that.

Example · php
<?php

use Illuminate\Support\Facades\Validator;

// A blank <input name="publish_at"> reaches the validator as null,
// because ConvertEmptyStringsToNull runs in the global middleware stack.
$blankFormField = ['publish_at' => null];

$without = Validator::make($blankFormField, ['publish_at' => 'date']);
$with    = Validator::make($blankFormField, ['publish_at' => 'nullable|date']);

var_dump($without->passes());
print_r($without->errors()->all());
var_dump($with->passes());

// bool(false)
// Array
// (
//     [0] => The publish at field must be a valid date.
// )
// bool(true)

nullable versus sometimes — they solve different problems

Both rule sets accept a missing key, because `string` and `min` skip absent attributes anyway. They diverge on an explicit null: `nullable` accepts it, while `sometimes|required` treats a sent-but-empty value as a real error. Pick `sometimes|required` for PATCH endpoints where sending a key means you meant to set it.

Example · php
<?php

use Illuminate\Support\Facades\Validator;

$absent  = [];                     // key not sent at all
$isNull  = ['nickname' => null];   // key sent, value null

$nullable  = ['nickname' => 'nullable|string|min:3'];
$sometimes = ['nickname' => 'sometimes|required|string|min:3'];

var_dump(Validator::make($absent, $nullable)->passes());   // bool(true)
var_dump(Validator::make($isNull, $nullable)->passes());   // bool(true)

var_dump(Validator::make($absent, $sometimes)->passes());  // bool(true)
var_dump(Validator::make($isNull, $sometimes)->passes());  // bool(false)

A nullable foreign key that must exist when supplied

A top-level category legitimately has no parent, so `parent_id` must accept null — but when a value is given, the `exists` query still runs and is still scoped to the caller's team. Without `nullable`, the `integer` rule would reject the null before `exists` was ever reached.

Example · php
<?php

namespace App\Http\Requests;

use Illuminate\Foundation\Http\FormRequest;
use Illuminate\Validation\Rule;

class StoreCategoryRequest extends FormRequest
{
    public function rules(): array
    {
        return [
            'name'      => ['required', 'string', 'max:255'],
            'parent_id' => [
                'nullable',
                'integer',
                Rule::exists('categories', 'id')
                    ->where('team_id', $this->user()->team_id),
            ],
        ];
    }
}

// echo json_encode($request->validated());
// {"name":"Hardware","parent_id":null}   for a top-level category

Discussion

  • Be the first to comment on this lesson.