filter_id
Returns the numeric filter ID for a filter's name, or false when no filter goes by that name.
filter_id(string $name): int|false- Added in PHP 5.2.0
Parameters
| Parameter | Type | Description |
|---|---|---|
$name | string | Name of a filter to look up, as returned by filter_list(). |
Return value
int|falseThe ID of the named filter, or false if no filter with that name exists.
filter_id() turns a filter's string name into the integer that filter_var() and friends expect. It is the inverse of the names returned by filter_list().
When to reach for it
You need it whenever the choice of filter is data rather than code — a validation rule stored in a database, a JSON or YAML schema, a form definition, or a column in a config table. Instead of building a giant match over constant names, store "validate_email" and call filter_id('validate_email').
It is also the cheapest way to feature-detect: if filter_id() returns false, the filter is not present in this build and you can fall back rather than pass a nonsense ID.
What trips people up
The names are the filter extension's own names, not the constant names with the prefix stripped. The integer validator is "int", not "validate_int". The boolean validator is "boolean". And the bare names "email" and "url" are the sanitization filters — the validators are "validate_email" and "validate_url".
Because a mistyped name yields false, and filter_var($v, false) is not a meaningful call, always check the return value before passing it on. When names come from user input, check them against your own allow-list first.
Example
When to use it
- Apply validation rules stored as strings in a database or JSON schema without a hand-written switch statement.
- Feature-detect whether a filter such as validate_domain exists in the running PHP build.
- Map a form-builder field type like "number" onto the right FILTER_VALIDATE_* constant at runtime.
Frequently asked questions
What are the valid filter names for filter_id?
They are exactly the strings returned by filter_list(), such as int, boolean, float, validate_email, validate_url, validate_ip, special_chars and callback. Call filter_list() on your own build to see the full set.
Why does filter_id('validate_int') return false?
Because the integer validator's registered name is int, not validate_int. The same applies to boolean and float; only the non-numeric validators carry the validate_ prefix.
Is it safe to pass a user-supplied name to filter_id?
filter_id itself is safe — it returns false for unknown names. The risk is that a user could pick a sanitizing filter where you expected a validating one, so match the name against your own allow-list before using it.
More examples
Filter rules stored as configuration
The <code>age</code> and <code>site</code> fields are filtered using IDs resolved from strings, while <code>phone</code> prints "unknown filter 'telephone'" because no such filter is registered. Checking for <code>false</code> is what stops a typo in the config from being passed to filter_var as an invalid ID.
<?php
$rules = ['age' => 'int', 'site' => 'validate_url', 'phone' => 'telephone'];
$data = ['age' => '34', 'site' => 'https://example.com', 'phone' => '555'];
foreach ($rules as $field => $name) {
$id = filter_id($name);
if ($id === false) {
echo "$field: unknown filter '$name'\n";
continue;
}
var_dump($field, filter_var($data[$field], $id));
}A safe named-filter helper
The first call prints <code>int(42)</code>. The second throws, because the integer validator is registered under the name <code>int</code> — this is the single most common mistake with filter_id, and turning it into an exception makes it visible immediately.
<?php
function applyNamed(string $name, mixed $value): mixed {
$id = filter_id($name);
if ($id === false) {
throw new InvalidArgumentException("No filter named '$name'");
}
return filter_var($value, $id);
}
var_dump(applyNamed('int', '42'));
try {
applyNamed('validate_int', '42');
} catch (InvalidArgumentException $e) {
echo $e->getMessage(), "\n";
}
Discussion