Regex Tester

A pattern that passes a mental check on paper often fails against real input: a greedy quantifier captures too much, a missing flag causes case mismatch, an anchor placement changes which lines match.

Paste the actual strings your code will process — log lines, user input, API responses — rather than constructed examples. Edge cases show up in real data, not in simple test strings you write yourself.

Flags change how the entire pattern behaves and are placed after the closing slash: /pattern/flags. Multiple flags can be combined freely.

g (global) — return all matches, not just the first. Without g, exec() and match() stop after the first match regardless of how many times the pattern appears.

i (case-insensitive) — treat uppercase and lowercase as equivalent. /error/i matches "Error", "ERROR", and "error".

m (multiline) — ^ and $ match the start and end of each line, not just the whole input. Without m, /^\w+/ only matches a word at the absolute start of the input.

s (dotAll) — . matches any character including \n. Without s, . skips newlines, so /start.*end/ fails when there is a line break between "start" and "end".

u (unicode) — full Unicode code-point support and stricter escape sequence parsing. Use when matching emoji or characters outside the Basic Multilingual Plane.

Parentheses (…) create a numbered capture group. When the pattern matches, each group's content is shown in the results panel labeled g1, g2, etc. Use capture groups to extract specific parts of a match — year, month, and day from a date string, for example, or a log level and message from a log line.

Named groups use the syntax (?<name>…) and behave identically to numbered groups but are identified by a label rather than an index.

Non-capturing groups (?:…) group tokens for quantifiers or alternation without creating a capture entry. Use (?:jpg|png|gif) when you want to match any of those three values but do not need to capture which one matched. Non-capturing groups keep the numbered index count lower and the match output cleaner.

Quantifiers (*, +, ?, {n,m}) are greedy by default: they match as many characters as possible while still allowing the overall pattern to succeed. This causes them to capture more than expected when the same character appears multiple times in the string.

Adding ? after a quantifier (*?, +?, ??, {n,m}?) makes it lazy: it matches as few characters as possible and expands only as far as necessary. The pattern still has to succeed — it just stops at the earliest opportunity.

Classic example: /<.+>/ on "<b>bold</b> and <em>italic</em>" matches the entire string from the first < to the last >. The greedy .+ consumes all the way to the end and backs off only as far as it must to find a final >. Switch to /<.+?>/g to match each individual tag instead.

Twelve characters have special meaning in regex syntax and must be escaped with a backslash to match them literally: . * + ? ^ $ { } [ ] ( ) | and \ itself.

The dot (.) is the most commonly forgotten escape. Without escaping, /3.14/ matches "3.14" but also "3X14" or "3 14" — any character in that position. The pattern /3\.14/ matches only the literal string "3.14".

In JavaScript regex literals (/pattern/), forward slashes must also be escaped (\/) because an unescaped slash ends the pattern. In new RegExp('string'), each backslash needs double escaping because the string itself consumes one level: write '\\d' to get the regex \d.

\d matches any digit 0–9. \w matches any word character (letters, digits, underscore — equivalent to [a-zA-Z0-9_]). \s matches whitespace: space, tab, newline, carriage return, and form feed. Each has an uppercase inverse: \D (non-digit), \W (non-word), \S (non-whitespace).

\b is a word boundary — a zero-width assertion at the position between a word character and a non-word character. /\bcat\b/ matches "cat" as a standalone word but not "catch", "scat", or "concatenate". It costs nothing in terms of characters consumed.

^ matches the start of the string. $ matches the end. Add the m (multiline) flag and they match the start and end of each line instead. Without m, ^ and $ only match the very beginning and very end of the full input.

These patterns cover tasks that come up frequently when processing logs, validating inputs, or extracting values from text. Test each against your actual data before using in production — edge cases in real strings often break patterns that look correct on a simple example.

Matches nothing: the most common cause is a case mismatch — /error/ does not match "Error"; add the i flag. The second most common cause is an anchor without the m flag: /^status:/g only matches if "status:" appears at the very start of the entire input; with multi-line text it misses every line except the first. A wrong character class — using [A-Z] when the input is lowercase — also returns zero matches.

Matches too much: a greedy quantifier (.* or .+) expands to the farthest possible position before backing off. The fix is to switch to lazy (*? or +?) or add a more specific character class instead of a dot. Also check whether missing ^ and $ anchors allow the pattern to match a substring inside a longer word.

Matches too little (stops after the first occurrence): this is almost always a missing g flag. Without g, exec() and match() return only the first match. If you are using .exec() in a loop and the pattern lacks g, lastIndex never advances and the loop runs forever. Add g to get all occurrences.