Developer

Regex Tester

Test regular expressions against your own text with live match highlighting, capture groups, and a regex replace preview — all computed instantly in your browser.

Try:

Pattern

Test String

How To Use

1.Type or paste a regular expression pattern into the Pattern field — no need to wrap it in slashes.
2.Toggle flags (g, i, m, s, u) to control how the pattern matches; g (global) is on by default so every match is found, not just the first.
3.Paste your text into the Test String box — matches highlight live as you type or edit either field.
4.Scroll the Matches list to see each match's full text, its position in the string, and any numbered or named capture groups it contains.
5.Switch to Replace mode to see a live preview of running String.replace with your pattern and a replacement string — use $1, $2, or $<name> to reference capture groups.
6.Load any of the common pattern examples (email, URL, phone number, date, IPv4) to see a working, well-tested regex you can adapt for your own use.

Examples

Email address

A common, practical email-matching pattern — highlights both addresses in the sample text.

URL

Matches both http and https URLs, including paths and query strings, case-insensitively.

Phone number

A flexible US-style phone number pattern that tolerates parentheses, dots, dashes, or no separators.

Named groups: date

Uses named capture groups (year, month, day) — see them labeled individually in each match's details.

IPv4 address

Matches dotted-decimal IPv4 addresses; doesn't validate that each octet is 0–255.

Replace mode: redact digits

Switches to Replace mode and swaps every digit for a bullet — a quick way to preview a redaction pattern.

About Regex Tester

What Is a Regular Expression?

A regular expression (regex) is a sequence of characters that defines a search pattern, used to match, locate, and manipulate text according to rules far more flexible than a plain substring search. Where a simple search looks for an exact sequence of characters, a regex can express concepts like 'one or more digits,' 'any character except a newline,' 'this word, but only at the start of a line,' or 'an optional group that may or may not appear' — all in a compact, standardized syntax supported (with minor variations) across nearly every programming language.

This tool uses JavaScript's native RegExp engine, the same one that powers pattern matching in every browser and in Node.js, so any pattern that works here will behave identically inside real JavaScript or TypeScript code using new RegExp() or a /pattern/flags literal.

Understanding Regex Flags

Flags modify how a regular expression's engine interprets and applies the pattern, without changing the pattern itself. The g (global) flag is arguably the most consequential for everyday use: without it, matching stops after the very first match is found anywhere in the string, which is rarely what you want when scanning a document or log file for every occurrence of something.

The i (ignore case) flag is essential whenever input casing can't be guaranteed to be consistent — user-typed text, for instance, rarely follows a predictable case convention. The m (multiline) and s (dotAll) flags both change how patterns interact with line breaks, but in opposite ways: m expands where ^ and $ anchor (to every line, not just the whole string), while s expands what . is allowed to match (including newlines, which it normally excludes). The u (unicode) flag ensures characters are interpreted by their full Unicode code point rather than by UTF-16 code unit, which matters specifically for characters (including many emoji and rare CJK characters) that are represented internally as a pair of code units — without it, a pattern can accidentally split such a character in half.

Capture Groups: Numbered and Named

Parentheses in a pattern create a capture group — a sub-match within the overall match that can be extracted separately. Groups are numbered left to right by their opening parenthesis, starting at 1 (group 0, implicitly, is the entire match). This numbering can get unwieldy fast in a pattern with many groups, which is exactly the problem named capture groups solve: writing (?<year>\d{4}) instead of a bare (\d{4}) lets you reference and display that group by the meaningful name year rather than by remembering it's specifically the third group in a complex pattern.

Both kinds of groups are available for reuse inside a replacement string in Replace mode ($1, $2, ... for numbered groups, $<name> for named ones), and both are exposed programmatically in real JavaScript code through a match object's array-index access (for numbered groups) and its .groups property (for named ones). Non-capturing groups, written (?:...), let you group parts of a pattern for the purposes of applying a quantifier or alternation without creating an extra numbered group — useful for keeping group numbering predictable in longer patterns.

Common Regex Pitfalls

Catastrophic backtracking is the most serious practical pitfall: certain pattern shapes, particularly nested quantifiers like (a+)+ applied against a string that almost — but doesn't quite — match, can cause the regex engine's search to grow exponentially slower with input length, effectively freezing the page or process. Patterns built from user-supplied input, or applied to untrusted or unusually long text, deserve extra scrutiny for this risk.

Greedy versus lazy quantifiers is another frequent source of surprising results: by default, .* is greedy and consumes as much text as possible before backtracking to satisfy the rest of the pattern, which can cause a pattern intended to match 'the shortest possible quoted string' to instead swallow far more text than expected, from the first quote all the way to the last quote in the string. Adding a ? after a quantifier (.*?) makes it lazy instead, matching as little as possible — often the fix for exactly this kind of over-matching. Forgetting to escape regex metacharacters that should be literal (., *, +, ?, (, ), [, ], {, }, ^, $, |, \) is the other classic mistake, especially when a pattern is built dynamically by inserting user-provided text directly into a regex without escaping it first.

FAQs

No — every match, highlight, and replacement is computed entirely in your browser using JavaScript's native RegExp engine (the same engine your browser uses to run any other JavaScript regular expression). Nothing you type into the Pattern or Test String fields is transmitted, logged, or stored anywhere outside the page. This is worth knowing if you're testing a pattern against real, sensitive sample data — production log lines, user input examples, or internal identifiers — since none of it ever leaves your machine.

The g (global) flag tells the engine to find every match in the string instead of stopping after the first one — this tool turns it on by default since testing usually means seeing all matches at once. The i (ignore case) flag makes letter matching case-insensitive, so /cat/i matches 'Cat' and 'CAT' as well as 'cat'. The m (multiline) flag changes how ^ and $ behave: normally they anchor to the very start and end of the whole string, but with m they additionally match at the start and end of each line within a multi-line string. The s (dotAll) flag changes what . matches: by default . matches any character except a line break, but with s it matches line breaks too, which is essential when you need a pattern to span multiple lines. The u (unicode) flag makes the engine treat the pattern as a sequence of Unicode code points rather than individual UTF-16 code units, which matters for correctly matching characters outside the Basic Multilingual Plane, like many emoji.

This almost always means the g (global) flag is turned off. Without it, JavaScript's regex engine — and this tool, which mirrors that exact behavior — stops after finding the first match, which is the standard, spec-defined behavior of a non-global regular expression. Turn on the g flag using the flag toggles above the pattern field, and every match in your test string will be found and listed instead of just the first one. This is a genuinely common source of confusion even for experienced developers, since it's easy to forget that /pattern/ and /pattern/g behave completely differently once you move beyond a single expected match.

A named capture group lets you label a part of your pattern with a name instead of relying on its numbered position, using the (?<name>...) syntax — for example, (?<year>\d{4})-(?<month>\d{2})-(?<day>\d{2}) captures a date's year, month, and day as named fields rather than as anonymous groups 1, 2, and 3. This tool automatically detects named groups in your pattern and displays them separately, labeled by name, in each match's details — which is far easier to read than counting parentheses to figure out which numbered group is which, especially in a pattern with many groups. Named groups are also directly usable in Replace mode using $<name> in the replacement string, and in real code, JavaScript exposes them on a match's .groups property.

Replace mode runs your pattern and test string through JavaScript's String.prototype.replace, showing you a live preview of the result as you edit the pattern, flags, test string, or replacement text — exactly what you'd get calling replace() in real code. The replacement string supports the standard JavaScript replacement patterns: $1, $2, and so on insert the corresponding numbered capture group, $<name> inserts a named capture group, $& inserts the entire match, and $$ inserts a literal dollar sign. If the g flag is on, every match gets replaced; if it's off, only the first match is replaced, mirroring exactly how replace() itself behaves depending on whether the regex is global.

The most common culprits are: forgetting to escape a special character that should be treated literally (a bare . matches any character, not a literal period — you need \. for that), a case mismatch when the i flag isn't enabled, whitespace differences that aren't visible when reading the text (tabs vs. spaces, or a trailing space), or a quantifier that's stricter than the actual data (\d{4} won't match a 3-digit or 5-digit number). It's also worth checking the m and s flags if your test string spans multiple lines — ^, $, and . all behave differently across line boundaries depending on whether those flags are set. This tool's live highlighting is specifically designed to make these mismatches visible immediately, since you'll see zero highlighted text the moment something doesn't line up.

Each match's position shows its start and end index within the test string, using standard zero-based indexing — meaning the very first character of the string is at index 0, not 1. A match reported as 'Position 5–10' starts at the 6th character (index 5) and ends just before the 11th character (index 10), covering 5 characters total. This is the same indexing scheme JavaScript's own String.prototype.indexOf, slice, and RegExp match objects use internally, so these numbers will line up directly if you're using the pattern you tested here inside actual code.

They're solid, widely-used starting points that correctly handle the overwhelming majority of realistic input, but no single regular expression perfectly validates something as genuinely complex as an email address or a phone number across every real-world edge case and international format — the official email specification (RFC 5322) alone permits far more syntactic complexity than almost any practical regex attempts to fully capture. Treat these examples as a strong, adaptable foundation: test them against your actual expected input format, and tighten or loosen specific parts (like the phone number's area code handling or the URL's supported protocols) to match your exact requirements before relying on them for strict validation in production.

An empty pattern field is treated as 'nothing to test yet' rather than as a technically-valid regex that matches the empty string everywhere — this avoids showing a wall of confusing zero-length matches before you've actually typed a pattern. Once you enter a pattern, matching runs against whatever is currently in the test string, including an empty test string (which correctly produces zero matches for any pattern that requires at least one character). If you do want to specifically test how a pattern behaves against an empty string, just leave the test string field blank while your pattern is filled in — it's a genuinely valid, informative test case for patterns using * or ? quantifiers that can match zero characters.

Regex Tester validates and previews pattern matching against your own text. These related developer tools handle other text-processing tasks you'll often reach for alongside regular expressions.

URL Encoder/Decoder

DeveloperPercent-encode or decode URL text — useful when a regex-extracted match needs to be safely inserted into a URL.

JSON Formatter & Validator

DeveloperFormat and validate JSON — handy for inspecting structured data before writing a regex to extract fields from it.

Case Converter

TextConvert text case — often used right after a regex extracts or replaces a substring that needs reformatting.

Find and Replace

TextPlain-text find and replace for when you need simple substitution without writing a regular expression at all.