How to Test and Debug Regular Expressions with Examples

Regular expressions are a compact way to describe patterns in text. They are powerful, but they are also easy to get slightly wrong: a small mistake can make a pattern match too much, too little, or nothing at all. The reliable way to work with them is to build patterns in small steps and test each change.

The WebToolkit Regex Tester uses the JavaScript regular-expression engine. Syntax and available features can differ in other engines such as Python, PHP, Java, or .NET, so a pattern that works here may behave differently elsewhere.

What is a regular expression?

A regular expression, or regex, is a pattern used to work with text. Common uses include:

Matching whether text fits a pattern
Searching for occurrences within text
Extracting parts of the text
Validating simple formats
Replacing text that matches a pattern

Regex is a good fit for many text tasks, but it is not the best tool for everything. Structured or deeply nested formats are usually better handled by a dedicated parser.

Basic regex building blocks

Common regular-expression tokens
Token	Meaning	Example
.	Any character except a newline by default	a.c matches abc
\d	A digit	\d\d matches 42
\w	A word character	\w+ matches word
\s	A whitespace character	a\sb matches a b
[abc]	Any one listed character	[abc] matches a
[^abc]	Any character not listed	[^0-9] matches x
^	Start of input or line	^Hi matches Hi...
$	End of input or line	end$ matches ...end
*	Zero or more	ab* matches a or abb
+	One or more	ab+ matches ab or abb
?	Zero or one	colou?r matches color
{n}	Exactly n times	\d{4} matches 2024
{n,m}	Between n and m times	\d{2,4} matches 123
( )	A capture group	(ab)+ captures ab
\|	Alternation, or	cat\|dog matches dog

Escaping rules depend on how you write the pattern. Inside a programming-language string, a backslash often has to be doubled, so \d in a pattern may be written as \\d in source code. In the Regex Tester's pattern field, you enter the pattern directly.

Start with a small test

A dependable debugging method is to grow the pattern gradually:

Test the smallest literal text you expect to match.
Add one token at a time.
Confirm the result after each change.
Add anchors such as ^ and $ last.
Add flags deliberately, one at a time.
Test both positive and negative examples.

Regex flags

The Regex Tester exposes the following JavaScript flags:

g, global, finds all matches instead of stopping at the first
i, case insensitive
m, multiline, so ^ and $ match at line boundaries
s, dot matches newline characters as well
u, unicode, for correct handling of Unicode patterns

Anchors and unexpected matches

Anchors control where a match may start or end. Without them, a pattern can match inside a larger string when you expected it to match the whole thing.

^ matches the start, and $ matches the end.
With the multiline flag, ^ and $ also match at the start and end of each line.
To validate a whole value, anchor both ends, as in ^\d+$.
Without anchors, ^\d+ or \d+ can match just part of the input.

Greedy versus lazy matching

By default, quantifiers are greedy: they match as much as possible and then give back characters only if needed. Adding a question mark makes them lazy, matching as little as possible.

The greedy pattern <.*> against <a> <b> matches the entire <a> <b> because .* consumes everything up to the last >.
The lazy pattern <.*?> against the same text matches <a> first, then <b> on the next match.
Greedy patterns are a common cause of matching more than intended.

Character classes

[abc] matches any one of a, b, or c.
[a-z] matches any lowercase letter in the range.
[^0-9] matches any character that is not a digit.
A hyphen is treated literally at the start or end of a class, and a closing bracket must be escaped when it should be literal.

Capture groups

Parentheses create a capturing group whose matched text you can read separately.
A group written as (?:...) is non-capturing, useful for grouping without keeping the result.
Groups are numbered from left to right by their opening parenthesis.
Named groups, written (?<name>...), are supported by the JavaScript engine and appear alongside numbered groups in the Regex Tester.

Common regex mistakes

Forgetting to escape special characters such as a literal dot or question mark
Using .* too broadly and matching more than intended
Missing anchors when full-string validation is required
Writing an incorrect character range
Assuming \d covers every Unicode digit in every configuration
Choosing the wrong flag for the task
Expecting one regex engine to behave exactly like another
Writing patterns that backtrack heavily and run slowly on certain inputs
Trying to parse deeply nested formats like full HTML or JSON with a single regex

How to use the WebToolkit Regex Tester

Enter the regex pattern.
Add the test text you want to check.
Select the flags you need, such as g and i.
Observe the matches as the tool runs the pattern.
Inspect the matched text along with numbered and named capture groups.
Adjust the pattern and test again.

Processing and privacy

The pattern and test text are sent to the server to compute matches and are not intentionally saved. Avoid pasting confidential text into any online tool.

Test your regular expression

Enter a pattern and sample text, choose flags, and inspect matches and capture groups.

Open Regex Tester

Practical examples

These examples are simplified to illustrate ideas, not to serve as complete production validators:

Find numbers: \d+
Validate a simple identifier: ^[A-Za-z_][A-Za-z0-9_]*$
Match email-like text: \S+@\S+\.\S+ (note that full email validation is far more complex than this)
Capture a simple date: (\d{4})-(\d{2})-(\d{2})
Collapse repeated whitespace: \s+ replaced with a single space
Match lines beginning with a prefix, using the multiline flag: ^ERROR

Performance and safety

Some patterns with nested quantifiers can cause heavy backtracking and become very slow on certain inputs.
Test your pattern against large and unusual inputs, not just short samples.
In server applications, add input size limits and timeouts around regex work.
Do not rely on regex alone for security-sensitive validation; combine it with proper parsing and checks.

Regex debugging checklist

Confirm which engine you are targeting
Test literal text first
Add pattern pieces one at a time
Confirm the flags you have selected
Check your escaping
Test cases that should not match
Inspect capture groups
Watch for greedy quantifiers matching too much
Test realistic input sizes

Frequently asked questions

Why does my regex match too much?

A greedy quantifier such as .* matches as much as possible. Make it lazy with .*?, use a more specific character class, or add anchors to limit the match.

What is the difference between * and +?

The star matches zero or more of the preceding item, so it can match nothing. The plus matches one or more, so it requires at least one occurrence.

What does the g flag do?

The global flag makes the pattern find all matches in the text instead of stopping at the first one.

Why does my regex work in one language but not another?

Different languages use different regex engines with different features and syntax. A pattern written for JavaScript may need changes to work in Python, PHP, Java, or .NET.

What are capture groups?

Capture groups are parts of a pattern in parentheses whose matched text you can read separately. They can be numbered, or named with (?<name>...) in JavaScript.

Can regex validate an email address?

A regex can catch obvious format problems, but fully validating every valid email address is complex. For real systems, combine a simple check with sending a confirmation message.

Why is my regex slow?

Patterns with nested quantifiers can backtrack heavily on some inputs, which is slow. Simplify the pattern, make quantifiers more specific, and test against large inputs.

Conclusion

The reliable way to write a regular expression is to build it in small steps, test positive and negative cases, and watch for greedy matching. Remember that behavior can vary between engines. To experiment as you learn, use the Regex Tester.

Working with structured text too? See how to fix common JSON syntax errors and URL encoding and decoding explained.

How to Test and Debug Regular Expressions