How to use the regex tester
A regular expression (regex) is a compact syntax for describing text-matching rules. It's used everywhere — form validation, log extraction, batch replacement, data cleaning. But regex is dense: get one character wrong and the meaning changes completely. A tool that shows you the matches as you type saves a great deal of time.
What this tool gives you
- Live highlighting: as you type the pattern, every match in the test text is marked — no button to press
- Match list: each matched piece of text and its position listed separately, easy to cross-check
- Capture groups: substrings captured by parentheses are highlighted in different colours, so you can check the grouping is what you intended
- Error reporting: when the syntax is wrong it tells you which kind of error it is (an unclosed bracket, say) instead of failing silently
- Cheat sheet: click a common pattern (phone number, email, ID card and so on) to insert it, saving you from writing and memorising
What the five common flags mean
gglobal: find every match instead of stopping at the first. Worth leaving on while testing.iignore case:/abc/imatchesABCandAbc.mmultiline: makes^and$match the start and end of each line rather than of the whole text. Essential for line-by-line validation.sdot matches newline: by default.doesn't match a line break; with this on,.matches any character including newlines.uUnicode mode: handles four-byte characters such as emoji and rare hanzi correctly. If your test text contains emoji and the results look wrong, try turning this on.
A few traps people fall into
Greedy quantifiers. .* is greedy by default and matches as much as possible. Matching <a><b> with <.*> returns the whole string rather than two tags. Change it to <.*?> (the question mark makes it lazy) for the behaviour you actually want.
Anchors and multiline. In the default mode ^\d+$ only matches when the entire text is a single number. To validate line by line you must turn on m.
Forgetting to escape. Writing a regex inside a JavaScript string means doubling the backslashes — a phone pattern becomes "^1[3-9]\\d{9}$". The input box here takes a regex literal, so a single backslash as in \d is correct.
Form validation needs anchors. Writing just [0-9]{11} will find a "phone number" inside abc13800000000xyz too. For validation you must bound it with ^...$ from start to end.
A performance note
Some patterns trigger catastrophic backtracking. For example (a+)+b against a long run of aaaa... can take exponentially longer and freeze the browser. If the page stops responding, the culprit is usually nested quantifiers — rewrite it in a more precise form such as a+b.
Frequently asked questions
Can I use the cheat-sheet patterns in production?
Yes, but adjust as needed. The phone number rule changes with numbering policy and needs updating when new prefixes are issued. The full ID card pattern only validates the format and whether the date is plausible — it doesn't verify the final check digit. And email is a practical simplification that covers the overwhelming majority of cases; a strictly RFC 5322-compliant pattern is far more complicated and usually not worth it.
Why does my regex work in another language but not here?
This tool uses the JavaScript regex engine, whose syntax differs from PCRE (PHP, Python's re). Three typical differences: JavaScript lacks some extended syntax beyond (?<name>), it has no conditionals or recursion, and it has no \A / \z anchors (use ^ and $). Named groups (?<name>...) are supported.
How do I match content that spans newlines?
Two ways: replace . with [\s\S], or turn on the s flag. The first is more portable and works in virtually every engine.
Is the test text saved?
No. All matching happens in browser memory and is cleared when the page refreshes. Nothing is uploaded.