Regex Tester

What a regex tester does, and why reading a pattern fails

A regular expression is a small language for describing the shape of text. This page compiles what you type with new RegExp(pattern, flags) and runs it against your test string using the JavaScript engine already in your browser, so the syntax accepted here is ECMAScript, the same dialect you get in Node.js and the browser console. It is not PCRE, not Python re and not POSIX grep.

The reason to run a pattern rather than read it is that regex fails quietly. A pattern that compiles will happily match the wrong span, capture one character too many, or find three matches where you expected thirty, and nothing in the source code says so. Reading a.*b does not tell you that the greedy .* ran all the way to the last b in the line. Highlighting the matches in place, with the index and the captured groups listed underneath, turns that guesswork into something you can see.

Three details of the output are worth knowing before you trust it. The tester honors your flags exactly, so without g it shows only the first match, which is the right behavior when you are checking an anchored validation pattern. Overlapping matches are not possible, because the engine resumes scanning at the end of the previous match. And a group that took part in a match but captured nothing is shown as an empty string rather than being omitted, which is how you catch an optional group that never actually fired.

Which flag and which tab for which job

• g global: find every match instead of stopping at the first. Turn it off when the pattern is anchored with ^ and $ for form validation, and on when you are pulling every address or error code out of a log.
• i ignoreCase: upper and lower case match each other. Useful for hex colors, UUIDs and HTML tags, where both cases occur in the wild.
• m multiline: ^ and $ match at every line break rather than only at the ends of the whole string. This is the flag people forget when a pattern that works on one line finds nothing in a pasted log.
• s dotAll: . also matches a newline. Needed when a match has to span lines, for example the body of a multi line comment.
• u unicode: treat the pattern as a sequence of code points and enable \p{...} property escapes. Required before \p{L} or \u{1F341} will compile, and the safer default whenever accented letters, CJK, or emoji appear in your data.
• y sticky: match only at the current lastIndex position. Mostly used when hand writing a tokenizer, rarely useful for ad hoc testing.
• The Match tab answers whether and where a pattern hits. The Replace tab answers what the text will look like afterwards, which is the question that matters before you run a find and replace across a repository.

How to build a pattern from a sample

1. Paste real text into the test field first, before you write anything. Patterns built against imagined input tend to break on the first line of an actual file.
2. Start from the loosest thing that could work. For an error code, begin with ERROR and watch it light up, then grow it into \bERROR\b.* once you can see what it is picking up.
3. Turn on g so you can see every hit at once, and m if your text has several lines and your pattern uses ^ or $.
4. Tighten one piece at a time. Swap . for a specific class such as [^\s] or \d, and replace .* with .*? if the highlight is running past where it should stop.
5. Wrap the part you actually want in parentheses so it becomes a capture group, then expand the details block and check that the first group holds exactly the substring you want, not the whole line.
6. Try to break it. Paste a line that should not match and confirm the count drops to zero. A validation pattern that has never been shown a bad input has not been tested.

How to do a find and replace with capture groups

1. Get the match right in the Match tab first. Replacing with a pattern you have not seen highlighted is how a bulk edit goes wrong.
2. Switch to Replace and write the replacement. Numbered groups are $1, $2 and so on, a named group is $<name>, the whole match is $& and a literal dollar sign is $$.
3. Keep g on for a bulk edit. Without it only the first occurrence changes, which is easy to miss when the preview is long.
4. Read the preview from the bottom as well as the top. Mistakes tend to hide in the last line, where an optional group did not fire and $2 quietly became an empty string.
5. Copy the pattern and the replacement into your editor and run the same edit there. Reformatting a date is a good first exercise: match (\d{4})-(\d{2})-(\d{2}) and replace with $3/$2/$1.

Named groups make a long replacement readable. Matching (?<year>\d{4})-(?<month>\d{2}) and replacing with $<month>/$<year> still says what it means six months later, which $2/$1 does not.

Getting the pattern into an editor, a shell or your code

The pattern in the box is the bare pattern, with no surrounding slashes. Where it goes next decides how much of it you have to escape:

• A JavaScript literal: wrap it in slashes and put the flags after, as /\d+/gi. Nothing else changes.
• A JavaScript string: every backslash has to be doubled, because the string literal eats one first. This is the single most common reason a pattern that worked in a tester stops working in code.
• VS Code and most editors: open Find, click the .* icon to enable regex, and paste the pattern without slashes. Case sensitivity and whole word are separate buttons rather than flags, and the replacement field uses the same $1 syntax as here.
• The shell: wrap the pattern in single quotes so the shell does not expand it, as in grep -E 'pattern' file.log. Note that command line tools use a different dialect, covered in the next section.
• Phones: press and hold in the field and choose Paste on iPhone, iPad and Android. The test area is a plain text field, so keyboard autocorrect can capitalize the first letter of a pattern; check the first character after pasting from a note.
• Sharing with a colleague: send the pattern, the flags and one line of sample input together. A pattern on its own is not reviewable, and the sample is what makes a bug obvious.

The same pattern in other languages and tools

Most of regex is portable. The parts that are not tend to be named groups, what the shorthand classes mean under Unicode, and whether the engine backtracks at all. In JavaScript, the dialect this page runs, the literal and the constructor differ only in escaping:

const re = /(?<user>[\w.+-]+)@(?<host>[\w.-]+)/gi
const same = new RegExp('(?<user>[\\w.+-]+)@(?<host>[\\w.-]+)', 'gi')
text.match(re)                // an array of every match, because of g
re.exec(text).groups.user     // a named capture from the next match

Python spells named groups differently and defaults to Unicode aware shorthand classes on str, so \d there matches digits in other scripts unless you ask for ASCII. It also has no \p{...} property escapes in the standard library:

import re
m = re.search(r'(?P<user>[\w.+-]+)@(?P<host>[\w.-]+)', text, re.IGNORECASE)
m.group('user')
re.findall(r'\d+', text, re.ASCII)   # ASCII digits only

Java uses the same (?<name>...) syntax as JavaScript, but its \d and \w are ASCII only until you compile with UNICODE_CHARACTER_CLASS, and every backslash has to be doubled inside the Java string literal. Go and Rust use the RE2 engine, which guarantees linear time by refusing to support backreferences and lookaround at all; a pattern with (?<=...) will not compile there, and the fix is to capture the context in a group instead.

On the command line the default is older and narrower than anything above. Plain grep and sed take POSIX basic expressions, where + and ? are literal characters unless escaped; adding -E switches both to extended expressions, which is the form most people mean. GNU grep also has -P for the PCRE dialect, which is the closest to what you tested here, but it is not present in the BSD grep that ships with macOS:

grep -E '[0-9]{3}-[0-9]{4}' contacts.txt    # extended, portable
grep -P '\d{3}-\d{4}' contacts.txt         # PCRE, GNU grep only
sed -E 's/([0-9]{4})-([0-9]{2})/\2\/\1/' dates.txt

Note the replacement syntax changes too: sed and most POSIX tools use \1 where JavaScript uses $1. Databases differ again. Postgres offers ~ and regexp_match with its own POSIX based flavor, MySQL 8 uses ICU expressions through REGEXP_LIKE, and SQLite understands the REGEXP operator but ships no implementation, so it raises an error until the application registers one. Treat a pattern that has to run in the database as a separate thing to test, not as a copy of this one.

Limits, privacy and honest caveats

What leaves your browser: nothing. The pattern and the test string are compiled and matched locally by your own browser and are never uploaded, logged or sent anywhere, so a real log excerpt or a customer record can go straight in without being scrubbed first. The tool keeps your last five pattern and text pairs in the localStorage of this browser so the history panel can restore them, and the Clear button there removes them.

A nested quantifier can hang your tab. The engine here backtracks, so a pattern such as (a+)+b against a long non matching string can try an exponential number of combinations. That is the same weakness behind the ReDoS denial of service attack when such a pattern reaches a server. Matching runs on the main thread of this page, so the tab will freeze rather than report an error. The match list is capped at 10,000 results as a safety valve, which means a very loose pattern on a very long text shows the first ten thousand matches only.

Regex is not a parser. HTML, JSON, CSV with quoted commas and source code are all nested or context sensitive, and no regular expression handles nesting correctly. Use a pattern to find candidates or to make a one off edit you will read afterwards, and a real parser when correctness matters. The same caution applies to email: RFC 5322 is far more permissive than any practical pattern, so validate loosely and confirm by sending a message.

Browser differences are small but real. Lookbehind, written (?<=...) and (?<!...), reached Safari in version 16.4 in 2023 after years in Chrome and Firefox, so a pattern that compiles on your laptop may report a syntax error on an older iPhone. If you see an error you cannot explain, that is the first thing to test.

Reading the highlight. Matches are marked with a yellow background, which is color alone. The details list under the result gives the same information as text, with the exact substring and its index for every match, so nothing in the output depends on being able to see the highlight.