Regex Tester: Learn and Test Regular Expressions Online

Regular expressions are concise patterns for finding text. They are useful for search, extraction, and basic input checks, but they become hard to maintain when a simple parser or explicit validation rule would be clearer.

Test a pattern in EveryTask

Open the Regex tester.
Enter a JavaScript regular-expression pattern without surrounding slashes—for example, \d+.
Choose any flags you need.
Paste sample text and review the matches.

The tester uses the browser’s JavaScript regular-expression engine. It lists the matches it finds; it does not run a replace operation or execute code from the text you paste.

Useful building blocks

\d — a digit; \d+ means one or more digits.
\w — a word character; \s — whitespace.
. — any character except a line break in the default mode.
^ and $ — start and end of input (or line with multiline mode).
[abc] — one character from a set; [^abc] — one not in the set.
(...) — a capture group; (?:...) — a non-capturing group.
?, *, +, and {min,max} — repetition.

Start with a small test string. Add one condition at a time so you can see exactly which change affected the result.

Flags supported by the tester

g — return all matches rather than stopping at the first.
i — case-insensitive matching.
m — make ^ and $ work at line boundaries.
s — allow . to include line breaks.
u — enable Unicode-aware matching.

Flags change the meaning of a pattern. For example, /^hello$/im can match HELLO on a line inside a multi-line string, whereas ^hello$ without flags is stricter.

Common mistakes

Forgetting to escape special characters. A period matches any character. Use \. when you mean a literal dot.

Using .* too broadly. It can consume more text than expected. Prefer a specific character class or a non-greedy form such as .*? when appropriate.

Treating regex as complete email validation. A basic pattern can catch obvious typos, but confirmation and server-side validation are still needed.

Testing only the happy path. Include empty text, malformed input, repeated values, and Unicode characters in your examples.

When not to use regex

Regex is not the right tool for nested structures such as arbitrary HTML or JSON. Parse those formats with a real parser. For JSON syntax, use the JSON formatter instead.

Build a pattern in small steps

Start by matching a literal word, then add one condition at a time. For example, match a date-like value with digits and separators before you try to enforce every calendar rule. Test examples that should match and examples that should fail. A small pattern you understand is more maintainable than a dense pattern copied from somewhere else.

Use grouping to make precedence clear. cat|dog means either word; (cat|dog)s? adds an optional plural ending to either. Use anchors only when you mean to match the whole input or a line boundary. Flags should be explicit because they can change the result substantially.

Debug unexpected matches

When a pattern matches too much, replace broad pieces like .* with a specific character class. When it matches too little, check escaping and whether g, i, m, s, or u changes the intended behaviour. Look at each match and capture group in the tester rather than only the final yes/no result.

Avoid catastrophic patterns on untrusted large input, particularly nested repetition such as ambiguous groups followed by * or +. Regex can be computationally expensive; server-side validation should include sensible limits and timeouts where relevant.

Practical examples

Use \d{5} to find a five-digit sequence. Use ^[^\s@]+@[^\s@]+\.[^\s@]+$ only as a basic shape check, not proof that an email address exists. Use \bword\b to find a whole word rather than part of a longer one. Test Unicode input if your users can enter it.

Should I validate everything with regex? No. Use parsers for structured formats and server-side rules for business logic.

Why does a regex work in one language but not another? Engines and supported features can differ; this tester uses JavaScript regex behaviour.

Test edge cases before reuse

Include empty input, repeated values, punctuation, line breaks, and Unicode characters when they are relevant to your users. A pattern that works only for one copied example is not ready for production validation. Keep the test text alongside the pattern so future changes can be checked quickly.

Use tests to explain intent

Keep examples of values that must match and values that must not. They serve as a lightweight specification for a pattern and make it easier to spot a regression when someone changes a group, quantifier, or flag. For important validation, pair the pattern with clear server-side rules and error messages.