# Intervention Validation fills the gaps in Laravel's own rule set

> Intervention Validation is a Laravel extension package that adds 37 validation rules for things Laravel does not check, such as IBAN, BIC, ISBN, credit card numbers, EAN, GTIN, IMEI, domain names and colour codes. It suits applications that accept formatted identifiers from users, and it registers itself through a service provider so the rules read like native ones.

**Intervention/validation** — Missing Laravel Validation Rules

- Repository: https://github.com/Intervention/validation
- Website: https://validation.intervention.io
- Stars: 677 · Forks: 68
- Language: PHP
- License: MIT
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/intervention-validation

## Rules for identifiers Laravel has no opinion about

Intervention Validation describes itself as an extension library for Laravel's own validation system, and the repository description is blunter: missing Laravel validation rules. The package adds rules to validate data such as IBAN, BIC, ISBN and credit card numbers.

The gap it fills is specific. Laravel's built-in rule set is about shape: required, string, size, numeric, email, url, unique. It does not check whether a bank account number satisfies its country checksum, whether a book number is a valid ISBN, or whether a colour code has the right number of hex digits for the format intended. Those are domain checks, and writing them per project is repetitive work that gets done badly.

The package provides 37 additional validation rules, and the README states they include multi language error messages and can be used like Laravel's own validation rules. It is built to work with the Laravel Framework version 10 and above, and it ships a service provider that is discovered automatically and registers the rules into your installation. There is no manual provider registration step and no config file to publish, which is why the install is one Composer command.

For a team whose domain involves invoices, payments or catalogue imports, that is a good deal of behaviour per line of setup.

## Installing the package and using a rule three different ways

The install is a single Composer requirement:

```bash
    $ composer require intervention/validation
```

The rules then behave like native Laravel rules, and the README shows the three calling styles side by side:

```php
use Illuminate\Support\Facades\Validator;
use Intervention\Validation\Rules\Creditcard;
use Intervention\Validation\Rules\Hexadecimalcolor;
use Intervention\Validation\Rules\Username;

$validator = Validator::make($request->all(), [
    'color' => new Hexadecimalcolor([3, 6]), // pass rule as object
    'number' => ['required', 'creditcard'], // or pass rule as string
    'name' => 'required|min:3|max:20|username', // combining rules works as well
]);
```

A rule can be passed as an object, which is the form you need when the rule takes constructor parameters. It can be passed as a string, which is the convenient form for a rule with no arguments. And it composes with the pipe syntax of ordinary Laravel rules, so a username field can require a length range and the username check in one string.

The object form is where the parameters live. Hexadecimalcolor takes an array of accepted lengths, here 3 and 6, which restricts the rule to shorthand and full six digit forms rather than the four and eight digit variants the rule supports by default.

## Rules that take parameters decide what actually passes

Roughly a third of the rules accept constructor arguments, and those arguments are the difference between a check that catches real mistakes and one that accepts or rejects too much.

Ean takes an array of lengths, defaulting to 8 and 13, so by default it accepts both EAN-8 and EAN-13, and you can narrow it to one. Gtin takes an array defaulting to 8, 12, 13 and 14, covering GTIN-8, GTIN-12, GTIN-13 and GTIN-14, and again you can restrict it to specific lengths. Isbn takes an array of lengths defaulting to 10 and 13, so a field that must be a modern ISBN-13 needs the array narrowed explicitly.

Hexadecimalcolor takes an array of lengths defaulting to 3, 4, 6 and 8, so the shorthand and full forms are allowed by default, and passing 3 and 6 excludes the alpha and alpha-plus-digit forms. DataUri is the odd one out, taking an optional array of media types rather than lengths, and it is the only rule in the visible list whose constructor argument is nullable.

The rest take no arguments at all. AustrianInsuranceNumber, Base64, Bic, Camelcase, Cidr, Creditcard, Domainname, Grid, Hslcolor, Hsvcolor, HtmlClean, Iban, Imei and Isin all have empty constructors, which means the format check is fixed and the only question is whether it suits your data.

## The rules cover money, codes, books and colours

The catalogue is worth scanning as a group, because it shows what kind of problem this package is aimed at.

The financial identifiers are the core: Creditcard, Iban, Bic, and the Austrian insurance number, which is the Austrian social security number. The retail and catalogue codes are next: Ean, Gtin, Isbn, Isin, Grid for the Global Release Identifier, and Imei for mobile equipment identity. Then there are the web and network formats, with Domainname, Cidr for Classless Inter-Domain Routing notation, DataUri, and Base64 encoded strings.

The text format rules are for user-facing input: Camelcase and Username, plus HtmlClean, which requires the field to be free of any HTML code, and the HSL and HSV colour code rules alongside Hexadecimalcolor.

Two observations. First, several of these are country-specific, the Austrian insurance number being the obvious one, so the package is not a universal identifier validator but a collection of rules you pick from. Second, the presence of rules for things like Imei, which identifies a handset, and HtmlClean, which screens for markup, means the package is used on forms that take values pasted from elsewhere rather than only on fields your own system generated.

## Error messages come from the language file, not the package

The multi language messages work the way Laravel's own messages work, and the README explains the mechanism in a short section.

To change an error message, you add the corresponding key to your own resources/lang/<language>/validation.php file, for example an entry for the iban rule with a custom string. The alternative is to add custom messages directly to the validator, as the Laravel documentation describes for manual customisation. Either way, the translations live in your application, not in the package.

That design is worth understanding before you adopt it. It means the package does not ship a set of language files you can point at, and it means the default message for a rule is whatever your application's validation language file already provides. If a key is missing from that file, the message you get for that rule is the framework's fallback rather than a translated string, so a full localisation pass means adding keys for every rule you actually use in every language you support.

The rules themselves are registered by the auto-discovered service provider, so the registration is automatic, but the wording is yours.

## A Docker setup that runs tests, static analysis and coding standards

The repository is a conventional PHP package with a src/ directory, a tests/ directory, a composer.json, a LICENSE and a CONTRIBUTING.md, and it carries the quality tooling that a published package needs: phpcs.xml.dist for coding standards, phpstan.dist.neon for static analysis and phpunit.dist.xml for the test suite. The README badge points at a build workflow for the tests.

The Dockerfile and docker-compose.yml are the part that tells you how the project expects itself to be worked on. The image is based on php:8.1-cli with the intl extension installed, plus git and zip, and it copies the Composer binary in from the composer image. The compose file defines three services that all build the same image and mount the project at /project, and each one runs a different tool through the entrypoint script: tests runs PHPUnit, analysis runs PHPStan with a 512M memory limit, and standards runs PHP_CodeSniffer.

So the container is a task runner rather than a deployment artefact. The consequence for you as a consumer is that the library is developed and checked against a specific toolchain, the intl extension in particular, which is what you would expect from rules that have to parse and compare formatted strings across locales.

The release history is regular: 4.6.3 on 2026-06-06, 4.6.4 on 2026-06-27 and 4.7.0 on 2026-07-11, with the last push to the develop branch on 2026-09-26. The licence is MIT.

## Conclusion

Adopt Intervention Validation if your Laravel application accepts structured identifiers such as IBAN, BIC, ISBN or credit card numbers and you would rather not write checksum rules yourself, since the package covers 37 formats and plugs into Validator::make the same way as built-in rules. Do not adopt it for general input hygiene, since Laravel's own rules already cover required, size, format and uniqueness, and do not treat a passing creditcard rule as proof a card is real, since it checks the number format and checksum only. Before you deploy, add your own message keys to the language file for the rules you use, confirm your Laravel version is 10 or above, and check the rules that take parameters, such as Ean, Gtin, Isbn, Hexadecimalcolor and DataUri, against the exact formats your data has, because those default lengths and media type lists decide what passes.

## FAQ

### How do I install Intervention Validation in Laravel?

Require the package with composer require intervention/validation. It comes with a service provider that is discovered automatically and registers the validation rules, so there is no manual provider registration and no configuration to publish.

### How many validation rules does Intervention Validation add?

The package provides 37 additional validation rules with multi language error messages, usable like Laravel's own rules. They cover identifiers such as IBAN, BIC, ISBN, ISIN, EAN, GTIN, IMEI, credit card numbers, domain names, CIDR notation, data URIs, base64 strings, HTML-free text, camel case, usernames and colour codes.

### How do I change the error message for a validation rule?

Add the corresponding key to your own resources/lang/<language>/validation.php file, for example an iban entry with your own string. Alternatively you can pass custom messages directly to the validator as the Laravel documentation describes.

### Which Intervention Validation rules accept parameters?

Ean takes an array of lengths defaulting to 8 and 13, Gtin an array defaulting to 8, 12, 13 and 14, Isbn an array of lengths defaulting to 10 and 13, Hexadecimalcolor an array of lengths defaulting to 3, 4, 6 and 8, and DataUri an optional array of media types. The remaining rules take no arguments.

### What does the creditcard rule in Intervention Validation check?

The rule requires the field to be a valid credit card number, and it takes no constructor arguments, so the accepted format is fixed. The README describes it as a format check against the payment card number specification.

## Sources

- [Intervention/validation on GitHub](https://github.com/Intervention/validation)
- [License: MIT](https://github.com/Intervention/validation/blob/develop/LICENSE)
- [Project website](https://validation.intervention.io)
- [README](https://github.com/Intervention/validation/blob/develop/README.md)
- [Releases](https://github.com/Intervention/validation/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/intervention-validation