PHP Regex Tester

How it works

What it does

The PHP Regex Tester lets you enter a PCRE pattern, optional modifiers, and a subject string to see match results, captures, and basic error reporting for invalid patterns. It mirrors how developers use preg_match / preg_match_all during debugging.

When to use it

• Building validation rules for forms
• Debugging a routing or log-parsing pattern
• Checking capture groups before writing replacement code

How input is processed safely

Only pattern matching runs inside guarded limits (size caps, timeouts/backtrack protections where applicable). The tool does not eval the subject as PHP, does not call preg_replace_callback with user PHP, and does not fetch URLs found in the text.

Examples

• Email-shaped patterns with named captures
• Multiline log extraction with the m modifier
• Invalid delimiter errors explained clearly

Common mistakes

• Catastrophic backtracking patterns on large subjects
• Forgetting PHP delimiter requirements (/pattern/)
• Using JavaScript regex assumptions that differ from PCRE

PHP uses PCRE2 (on modern builds) with delimiter-wrapped patterns. Modifiers like i, m, s, u, and x change matching semantics substantially. The tester shows captures so you can wire preg_match results into typed PHP code with fewer surprises.

Protect yourself from pathological patterns. Nested quantifiers on large subjects can burn CPU. Prefer possessive quantifiers or simpler parsers for hot paths, and keep subject sizes reasonable while experimenting online.

When a pattern “works” here but fails in code, compare delimiters, modifiers, and whether you used single-quoted PHP strings that alter backslash handling.

Practical tips

• Keep inputs small and representative; huge pastes slow feedback and raise risk of accidental secret disclosure.
• After using PHP Regex Tester, verify the result in your own environment (correct SAPI, correct host, correct project root).
• Cross-link findings to ZendStudio.net PHP error guides and IDE setup pages when the next step is configuration rather than code edits.
• Prefer repeatable project tooling (CI, Composer scripts, IDE inspections) for repo-wide enforcement; this page is for interactive problem-solving.

Privacy note

Subjects may be production logs. Redact emails, IPs, and tokens. Prefer synthetic examples when possible.

Safety notes

• Submitted tool contents are not written to analytics or search logs.
• This site never evaluates arbitrary PHP from the browser.
• Generated configs are starting points—validate on a staging host before production.