How Laravel Handles Required, Nullable, and Present Validation Rules

When Laravel checks form or API input, a field can be absent, have a value, or be sent as null or an empty string. Validation rules tell Laravel how to handle each case. This matters when a request updates only some fields: Laravel can accept an omitted field while a separate rule determines whether a submitted null passes.

Each Laravel rule handles a different case. required rejects missing or empty values. present requires the input to include the field, even if its value is empty. nullable allows null and skips ordinary validation rules for that value. sometimes skips a field’s rules when the field is absent. Knowing how Laravel checks for a field and handles required rules and null values makes rule combinations easier to predict.

How Laravel decides whether to run a rule

Laravel first checks whether the input contains the field. A field is present when its key exists in the input, whether or not its value is useful or nonempty. Laravel then decides which rules to run. It runs required and present even when a field is missing; these are called implicit rules. Ordinary rules, such as integer or email, generally do not fail a missing field on their own. These checks explain the documented difference between sometimes and nullable.

For example, integer alone does not require a field to appear. If age is absent, the integer check is skipped. Add required|integer, and Laravel checks that age exists and is nonempty, then checks that its value is an integer. Add present|integer, and Laravel checks that the key exists, then applies the integer check to its value.

These results assume no other rules apply to the field. nullable does not require a field, and sometimes does not make every submitted value valid. Each rule controls a different part of Laravel’s decision.

What required, present, and nullable check

Use required when the request must provide a meaningful value. Laravel rejects a missing field, null, and an empty string. A rule such as required|email therefore checks both that the email value is supplied and that it has an acceptable email format.

Use present when the request must include the field, but its value may be empty or null. For example, present|nullable|integer rejects input without an age key. It accepts age => null. When age has a non-null value, the rule checks that value as an integer. The Laravel validator’s validatePresent method checks whether the field exists in the input; a framework issue discussing that method shows the presence check in context.

Use nullable when null is an allowed value. Laravel then skips ordinary rules for that field when its value is null. It still runs implicit rules, so required|nullable rejects a missing or null value: required still applies. By contrast, nullable|integer allows a missing field and accepts null, while checking non-null values as integers.

An empty string and a missing field are different inputs. In a typical Laravel request, the TrimStrings and ConvertEmptyStringsToNull middleware trim strings and turn empty strings into null. Validation then receives a present field with a null value when a form submits an empty field. The reported middleware behavior helps explain why nullable accepts an empty form field while required rejects it. If code sends an unmodified empty string directly to the validator, the validator receives that string instead of null.

What sometimes skips

The sometimes rule makes the rest of a field’s rules conditional on the field being present. If email is absent, sometimes|required|email skips validation for email. If email is present but empty, Laravel runs required, which fails. If it contains a nonempty value, Laravel also checks the email format. This behavior is illustrated in the comparison of sometimes with sometimes|required.

The distinction from nullable is clearest when the field is present with null. With sometimes|integer, Laravel runs integer on a present null value, which fails; with nullable|integer, it skips that check, as shown in the worked example comparing those rules.

Laravel also supports conditional validation with a sometimes callback. For example, a callback can add a required rule for a reason field when another input says a game was declined. The callback decides whether Laravel adds the rules. By contrast, the sometimes rule in a field’s rule list tells Laravel to run those rules only when that field is present.

Choosing a rule for partial updates

For a partial update, choose rules based on what the request means:

• Use sometimes|required|email when the client may omit email; any email it submits must be nonempty and valid.
• Use present|nullable|integer when the client must send age, and null is an allowed way to clear it.
• Use nullable|integer when the client may omit age or send null, and non-null values must be integers.
• Use required|integer when the client must supply an integer value.

These rules check input on the server, where validation matters because clients can bypass browser-side checks. Test each rule with at least three inputs. Include one case where the key is omitted, one where it is set to null, and one where it is an empty string. For HTTP requests, account for middleware that turns empty strings into null.

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