Why this matters

WordPress 6.9 modernized and standardized how core validates and scrubs UTF-8 data. If your plugin or theme manipulates user input, content, or external data sources, you should rely on the new/standardized helpers to ensure consistent behavior across environments (with or without mbstring).

Key public functions (what you should use)

• wp_is_valid_utf8( string $string ) : bool — checks whether a byte sequence is valid UTF-8. Use this as the canonical validator.
• wp_scrub_utf8( string $string ) : string — replaces invalid UTF-8 sequences with the Unicode replacement character (U+FFFD). Use this to sanitize strings that will be displayed or stored.
• wp_check_invalid_utf8( string $text, bool $strip = false ) — legacy checker/stripper to maintain backward compatibility. Prefer the two functions above for clarity.
• is_utf8_charset( ?string $charset ) : bool — checks whether a given charset (or the site charset if null) is UTF-8.

Legacy & deprecated helpers

seems_utf8( $str ) has been deprecated as part of the 6.9 modernization. It remains in core for compatibility, but you should stop using it in new code and migrate existing code to wp_is_valid_utf8().

Internal and fallback helpers (for core and advanced debugging)

WordPress ships pure-PHP fallback implementations so the behavior is consistent even if extensions like mbstring are not present:

• _wp_scan_utf8( string $bytes ) — low-level scanner used internally.
• _wp_is_valid_utf8_fallback( string $bytes ) — fallback validator used by wp_is_valid_utf8() when native helpers are not available.
• _canonical_charset( string $charset ) — internal normalizer for charset names.

Notes about PHP native functions

Historically PHP provided utf8_encode() / utf8_decode(), but they are discouraged for modern code; prefer mb_* functions with explicit encodings (for example, mb_convert_encoding()) or the WordPress helpers listed above. WordPress may polyfill or shim behavior if PHP removes these functions in future releases, but plugin authors should avoid relying on them.

Developer tip: use the IDE stub for autocomplete

Below is a compact PHP stub file containing the public and relevant internal UTF-8 functions present in WP 6.9 (beta 3). Put it in your project (for example: stubs/wp-utf8-stubs.php) so your editor can pick up signatures and docblocks for autocompletion and quick reference.

Practical examples

Quick usage patterns you can copy into plugin code:

// validate before saving
if ( ! wp_is_valid_utf8( $value ) ) {
    $value = wp_scrub_utf8( $value );
}

// check site charset
if ( is_utf8_charset() ) {
    // site uses UTF-8
}

Migrating old code

If your code uses seems_utf8() or directly attempts to strip invalid bytes, update it to use the modern helpers. The two-step pattern below is clean and explicit:

// preferred: explicit validation + scrub
if ( wp_is_valid_utf8( $input ) ) {
    $clean = $input;
} else {
    $clean = wp_scrub_utf8( $input );
}

Final notes

WordPress 6.9’s UTF-8 modernization improves consistency across environments and reduces surprises when dealing with external data. For plugin authors, the most important functions to remember are wp_is_valid_utf8() and wp_scrub_utf8(). Keep your code explicit and prefer these helpers over ad-hoc or environment-dependent logic.