Checking a string's length is one of the most common rules in form validation. This RFC from Masaki Kagaya adds a filter for it, FILTER_VALIDATE_STRLEN, which counts length in Unicode code points from UTF-8 text. A code point is a single Unicode character, so an emoji counts as one instead of four bytes.

How it works

You pass min_len, max_len or both:

filter_var("hello😀", FILTER_VALIDATE_STRLEN, [
    "options" => [
        "min_len" => 6,
        "max_len" => 6,
    ],
]);

This passes. The string is exactly 6 code points long, so you get the original string back.

The rules:

  • You must set at least one of min_len or max_len.
  • If you set both, min_len can't be larger than max_len.
  • On success, you get the original string back.
  • On failure, you get false, or null with FILTER_NULL_ON_FAILURE.
  • max_len can be 0, in which case only an empty string passes.

The filter only checks length. It doesn't verify that the text is valid UTF-8, because a filter can only return one result and couldn't tell you which check failed. Whether PHP needs a separate UTF-8 validation filter is left for another time.

The RFC also explains a couple of design choices. It counts code points rather than grapheme clusters (what a reader sees as one character) because code points give a stable count. And it uses new option names instead of reusing min_range and max_range, since those are meant for numbers.

What it means for existing code

Nothing breaks. It's a new filter, and the existing filters don't change.

Where it stands

It's a draft, first written on March 19, 2026, and it targets PHP 8.6. There's an implementation pull request, but no vote yet.