Regex Lab

Separate pattern, flags and test text

Enter the pattern in its editor, the sample in the test-text editor and flags in their separate field. Start with a small sample whose expected matches you can state. Run Find matches, inspect captures and offsets, then test a near miss. The absence of a match can be as informative as a successful one when you are designing validation rules.

Only move to Preview replacement after checking the matches. Replacement strings follow JavaScript conventions for the whole match and captured groups. Keep the original text and inspect the preview before using it in a file. Inspect structure describes parsed syntax; it does not provide an AI-generated explanation or prove that the pattern expresses your intended rule.

Design both positive and negative examples

The included pattern groups ASCII letters. Run it against the supplied mixed text and inspect the captures. Add an accented word and a line break to see whether the pattern’s explicit character range matches your real language requirement. Do not infer full Unicode word support from a successful English example. Change one assumption at a time so you can explain each result.

For a migration task, preview a replacement on a short representative extract rather than an entire customer file. Include missing values, punctuation and repeated delimiters in the test set. A pattern that performs well on the happy path may still match unintended spans or fail on adversarially repetitive input.

Isolation bounds the experiment, not production risk

The browser’s RegExp dialect is not PCRE or every server-side regex engine. Workers are terminated when computation exceeds the configured limit, and displayed matches are capped with a truncation notice. A bounded experiment here does not make a pathological pattern safe in a production request handler. Apply appropriate input limits and testing in the actual destination runtime.