While backfilling tests on a legacy client project, I discovered an inconsistency in how Laravel's request helpers handle default values.
Consider this code:
$request->validated('category', 'DEFAULT'); // returns null - the default is ignored
$request->post('category', 'DEFAULT'); // returns 'DEFAULT' when category is null
Why the difference?
The post(), query(), and cookie() methods use the ?? null coalescing operator internally, so the default is returned when the value is null OR if the field is missing.
But input() and validated() use data_get(), which only returns the default when the field is completely missing.
A null value is still considered "found", so your default is ignored.
When would this happen in practice?
It's actually pretty common.
An empty HTML form field combined with Laravel's default ConvertEmptyStringsToNull middleware results in a null value being sent to your controller.
To be clear, this isn't really a bug, it's just an inconsistency to be aware of. If anything, it reinforces the importance of consistency in your own code.
My recommendation: always use the validated() or safe() helpers.
Not only will you avoid this inconsistent default value handling, but you will improve security by only accessing validated data anyway.
Here to help,
Joel
P.S. Want to level up your validation skills? Check out our book Mastering Laravel Validation Rules.
