Processed entirely on your device — nothing is uploaded
How to use the regex tester
- 1Type a pattern in the box, without the surrounding slashes.
- 2Set the flags you need — g, i, m and the rest are explained as you add them.
- 3Paste your test string below.
- 4Read the highlighted matches and the group breakdown.
Testing against the engine you actually use
Regular expressions are not one language. The syntax accepted by JavaScript differs from PCRE, from Python's `re`, from Go's RE2 and from POSIX in ways that bite. Lookbehind assertions were unsupported in JavaScript until recently and are still absent from Go. Atomic groups and possessive quantifiers exist in PCRE and not in JavaScript. Named group syntax differs.
This tester runs your pattern through the browser's own regex engine — the same one that will execute it in your application. A pattern that works here works in JavaScript, and one that throws here would throw in your code. That is worth more than it sounds, because a tester built on a different engine will happily accept syntax your runtime rejects.
It also means the semantics match: the same greediness, the same backtracking behaviour, the same treatment of unicode. If you are writing for a different language, treat the results as indicative rather than authoritative.
Reading the output
Matches are highlighted in the test string itself, which is the fastest way to spot a pattern that is matching more or less than you intended. A pattern that looks correct but has swallowed the text between two matches is instantly obvious when you can see it.
The table below lists each match with its position and its capture groups. Groups are where most real work happens — a pattern that identifies a date is useful, but one that hands you the day, month and year separately is what you actually need. Named groups appear by name, which makes patterns far more readable than counting parentheses.
Zero-length matches deserve a mention because they confuse everyone at some point. A pattern like `\b` or `a*` can match the empty string at a position, which shows as an empty match in the table. It is not a bug; it is what the pattern says.
The flags, and the one that catches people
The global flag makes the engine find every match rather than stopping at the first. This tester always finds all matches so you can see the full picture, but remember that without `g` in your code, `match` returns only the first.
The `g` flag has a genuine trap in JavaScript: a regex object with `g` set keeps a `lastIndex` between calls to `test` and `exec`. Calling `test` twice on the same string with the same regex object can return true then false, because the second call resumes where the first stopped. This causes real bugs in validation code and is the single most common JavaScript regex surprise.
The multiline flag changes `^` and `$` to match at each line rather than at the ends of the whole string. Dotall makes `.` match newlines, which it otherwise does not — a frequent cause of patterns that mysteriously fail on multi-line input.
Writing patterns that will not hurt you
Prefer specificity to cleverness. `[0-9]{4}-[0-9]{2}-[0-9]{2}` is longer than a compressed alternative and immediately readable six months later. Regular expressions are written once and debugged repeatedly.
Beware catastrophic backtracking. Nested quantifiers over overlapping alternatives — patterns of the shape `(a+)+b` — can take exponential time on input that nearly matches. This is a real denial-of-service vector when a pattern is applied to user input, and it is why some systems ban user-supplied regular expressions outright. If a pattern hangs on a long string here, that is what is happening.
And know when to stop. Parsing HTML, email addresses to the full RFC, or nested structures with a regular expression is a well-trodden road to misery — those are not regular languages, and a pattern that appears to work will fail on input you have not thought of. Use a parser.
Frequently asked questions
Which regex flavour does this use?
JavaScript's own engine, running in your browser. A pattern that works here works in JavaScript. Other languages differ — notably in lookbehind, atomic groups and named group syntax.
What is the lastIndex trap?
A regex with the `g` flag remembers its position between `test`/`exec` calls, so calling `test` twice on the same string can return true then false. It causes real validation bugs.
Why does my pattern not match across lines?
`.` does not match newlines by default — add the `s` flag. And `^`/`$` only match the string ends unless you add `m`.
What is a zero-length match?
A pattern like `\b` or `a*` can match the empty string at a position. It appears as an empty match in the table and is expected behaviour.
Why did my pattern hang?
Almost certainly catastrophic backtracking from nested quantifiers over overlapping alternatives. It is also a denial-of-service risk if the pattern runs on user input.
Is my test data uploaded?
No. The pattern and the text stay in the page.