Regex тестер

Test regular expressions live, in real JavaScript

This free regex tester highlights every match the instant you type, using your browser's genuine JavaScript regex engine — so what matches here is exactly what will match in your frontend code or Node.js. Toggle any of the six flags (g, i, m, s, u, y), and invalid patterns show the actual engine error message instead of failing silently.

Below the live highlight you get a full match list — every match with its position plus all capture groups, numbered and named — and a replace panel that previews substitutions with $1, $<name> and $& backreferences as you type. When the pattern works, click Copy as JavaScript to grab ready-to-paste code.

A focused alternative to regex101.com and regexr.com

Heavyweight testers like regex101.com support PCRE, Python, Golang, and .NET flavors alongside JavaScript — useful when you're comparing engines, but often more than you need when you just want to debug a JS pattern. regexr.com surfaces community patterns and provides a reference guide. Both require navigation through multiple tabs to get from a match result to a replace preview.

This online regex tester answers the three questions that matter most day-to-day on one clean screen: does it match, what did it capture, and what does the replace produce? No flavor selection, no account, no upload. Unlike regexpal.com (which shows highlights only) or debuggex.com (which focuses on visual railway diagrams), this tool adds per-match capture-group extraction and live replace preview with backreference support.

Common regex patterns, one click away

The built-in library inserts battle-tested patterns with realistic sample text: email address, URL, IPv4 address, ISO date, 24-hour time, hex color, URL slug, international phone number, number (integer/float) and HTML tag. Each loads with valid and invalid examples so you can see precisely where the pattern's edges are.

They're starting points, not gospel — tweak them in place and watch the highlight respond. The samples deliberately include edge cases (like 999.999.1.1 for IPv4) so you learn what each pattern rejects, not just what it accepts. This is far faster than copying a pattern from Stack Overflow and guessing whether it handles your edge cases.

Capture groups, lookarounds, and all six flags — fully supported

Modern JavaScript regex has powerful features: named groups (?<year>\d{4}), lookahead (?=…) and lookbehind (?<=…), Unicode property escapes with the u flag, and sticky matching with y. This tester supports all of it, because it is the JavaScript engine. The match panel breaks out each group per match so extraction logic is verifiable at a glance.

The m flag demo is a favorite: with it, ^ and $ anchor to every line of your test text — paste a log file and watch a ^ERROR pattern light up each offending line. Toggle s to make . match newline characters inside multiline strings without workarounds. Every result you see here is the same one your code will produce.

Learn regex faster with the built-in cheatsheet

The collapsible regex cheatsheet covers the tokens you'll reach for daily — character classes (\d \w \s), anchors (^ $ \b), quantifiers (* + ? {n,m} and their lazy forms), groups, alternation, backreferences and all four lookarounds. Keep it open while you experiment; seeing a token's effect highlighted live is the fastest way regex actually sticks.

Start simple: match a literal word, add a character class, then a quantifier, then a group. Five minutes of live feedback in a regex playground teaches more than an hour of reading syntax tables. Works on mobile too — the layout adapts for smaller screens, so you can debug patterns on iPhone or Android without any app install.

NFA vs DFA: why backtracking exists and how it can hurt you

Nearly every programming language regex engine — JavaScript, Python, Ruby, Java, PHP — is built on a Non-deterministic Finite Automaton (NFA). An NFA tries each alternative in order, remembering where it was so it can backtrack and try another path if a branch fails. This approach is what makes features like backreferences and lookaheads possible: a Deterministic Finite Automaton (DFA) — the engine used by tools like awk and egrep — can guarantee linear-time matching but cannot support those constructs because it processes each character exactly once without memory of earlier choices.

The cost of the NFA approach is catastrophic backtracking. The classic illustration is the pattern (a+)+ applied to a string like aaaaab. The outer group can split the inner matches in an exponential number of ways before concluding no match exists, causing the engine to explore 2ⁿ paths for a string of length n. This is the mechanism behind ReDoS (Regular Expression Denial of Service) attacks: a server that validates user input with a vulnerable pattern can be frozen by a carefully crafted string of a few hundred characters. The fix is to eliminate ambiguity — use atomic groups or possessive quantifiers where supported, avoid nested quantifiers over the same characters, and prefer negated character classes (for example [^,]* instead of .*? before a comma) to give the engine a deterministic stopping point.

Testing your pattern against a deliberately malicious input is easy in this tester: paste a long string of repeated characters that your pattern is designed to reject, switch to single-character stepping in your browser DevTools if the engine hangs, then refactor until the rejection is instant. Spotting the problem here costs milliseconds; spotting it in production can cost an outage.

Lookaheads and lookbehinds: match with context, consume nothing

Lookaround assertions let you attach conditions to a match without including the surrounding text in what the engine consumes. A positive lookahead (?=...) says 'the current position must be followed by this'; a negative lookahead (?!...) says 'must NOT be followed by this'. Their mirror images, positive lookbehind (?<=...) and negative lookbehind (?<!...), impose the same constraint on what precedes the match. Because lookarounds are zero-width — they assert a condition but do not advance the cursor — they're ideal when you need context to decide whether to match but don't want that context captured or consumed.

Two concrete use cases illustrate why they're indispensable. Password validation often requires that a string contain at least one digit AND at least one letter. Rather than enumerating every combination, you write two separate lookaheads anchored at the start: ^(?=.*\d)(?=.*[A-Za-z]).+$ — the engine checks both conditions at position zero before committing to the rest of the match. Price extraction shows the lookbehind: to pull numeric values from text like '€12.99' and '$4.50' without capturing the currency symbol, use (?<=[$€£])\d+\.\d{2}. The symbol is required to be present but is not included in what match() returns.

JavaScript's V8 engine has supported lookbehinds since Chrome 62 (2017), so they're safe to use in any modern browser or current Node.js version. One important nuance: inside a lookbehind, the pattern is matched right-to-left, which means some complex patterns behave unexpectedly — variable-length lookbehinds in particular can produce surprising results. Paste your pattern here and inspect each match's start/end index to verify the cursor position behaves as you intend.

Named capture groups and non-capturing groups

By default, every set of parentheses in a pattern is a numbered capture group — the first opening paren is group 1, the second is group 2, and so on. This works fine for small patterns but becomes brittle the moment the pattern grows: insert a new group near the start and every $2 reference in your replacement string shifts by one. Named capture groups solve this. In JavaScript and most PCRE-compatible languages you write (?<name>...); in Python you write (?P<name>...). The captured value is then accessible by name rather than position: match.groups.year in JavaScript or match.group('year') in Python. A date pattern like (?<year>\d{4})-(?<month>\d{2})-(?<day>\d{2}) makes the intent of each group self-documenting, survives pattern refactors without breaking downstream code, and lets you reference the capture in a replacement as $<year>.

When you need grouping for structure or alternation but have no interest in capturing the matched text, use a non-capturing group (?:...). It behaves identically to a capturing group for matching purposes but does not allocate a slot in the match array, which keeps your group numbering clean and saves the engine a tiny amount of memory per match. A pattern like (?:https?|ftp):// groups the protocol alternatives without polluting the capture list. As a rule of thumb: use (?:...) whenever you're grouping for precedence or alternation and (?<name>...) whenever you intend to extract the value — reserve plain (...) only when you need the group numbered for a quick backreference in a one-off replacement.

The match panel in this tester lists every named and numbered group per match, making it straightforward to verify your extraction logic. If a group shows undefined, either the branch that contained it did not participate in the match (a normal result in alternation patterns) or you accidentally used a non-capturing group where a capturing one was intended. Both conditions are immediately visible here before you commit the pattern to code.

Common practical patterns worth knowing

Certain patterns appear in nearly every codebase, and understanding why they're written the way they are is as important as memorising the syntax. Email is the canonical example of a deceptively hard problem: the full grammar in RFC 5321 permits characters like +, quotes, and even spaces in the local part, which means a truly compliant regex would run to hundreds of characters and still fail edge cases. The pragmatic solution is to validate loosely — ^[^\s@]+@[^\s@]+\.[^\s@]+$ — and confirm deliverability by sending an actual message. A UUID (version 4) is reliably matched with [0-9a-f]{8}-[0-9a-f]{4}-4[0-9a-f]{3}-[89ab][0-9a-f]{3}-[0-9a-f]{12} (case-insensitive flag recommended). An ISO 8601 date like 2024-06-15 uses \d{4}-(0[1-9]|1[0-2])-(0[1-9]|[12]\d|3[01]) — the alternations in each segment enforce calendar-plausible ranges without needing a parser.

A URL slug — the lowercase hyphenated string in a web address — is one of the simplest reliable patterns: ^[a-z0-9]+(?:-[a-z0-9]+)*$. An IPv4 address is commonly written as four groups of (?:25[0-5]|2[0-4]\d|[01]?\d\d?) joined by escaped dots; the alternation in each octet enforces the 0–255 range that a naive \d{1,3} cannot. Phone numbers are a case where regex is the wrong primary tool: number formats vary so drastically by country that a single international pattern becomes unmaintainable. The recommended approach is to strip all non-digit characters with [^\d+], then validate length and country prefix in code. Credit card numbers can be checksum-verified in JavaScript with the Luhn algorithm — a regex can confirm the digit count and spacing but cannot validate the Luhn sum, so use a regex to sanitise input and a short function to verify authenticity.

These patterns are worth internalising not because memorised regex is faster to type, but because understanding the structure of each one — why the email regex punts on full RFC compliance, why the IPv4 regex uses alternation rather than a simple \d{1,3} — sharpens your instinct for when regex is the right tool versus when a proper parser or library function will serve you better. Load any of these from the built-in library, then deliberately break them with edge-case inputs to see exactly where each pattern's boundaries lie.