Test JavaScript regular expressions live against your own text. See matches highlighted instantly, with index positions and capture groups for every match.
| # | Index | Matched Text | Capture Groups |
|---|
Enter a pattern and test string to see matches
The regex tester at NeftCal is a free, browser-based tool for live-testing JavaScript regular expressions against your own text. Type a pattern and flags, paste a test string, and every match is highlighted instantly, with a details table showing each match's zero-based index and any capture groups it produced. Because it runs on the native JavaScript RegExp engine — the same implementation used by every browser and Node.js — what you see here is exactly what your production code will do. No signup, no uploads, no network calls: the entire tool runs locally on your device.
It compiles your pattern with the standard RegExp constructor, validates the flags field (g, i, m, s, u, y — no duplicates), and scans the test string using String.prototype.matchAll() when the g flag is set, exactly mirroring JavaScript runtime behavior. Every match is rendered inline as a highlighted span, and a table beneath lists each match's number, start index, matched text, and capture groups — with (undefined) shown for optional groups that did not participate. Invalid patterns and flags surface a clear error message instead of an uncaught exception.
It's built for web and Node.js developers validating form input, parsing logs, or writing search-and-replace routines; data engineers cleaning and extracting fields from messy text; QA engineers sanity-checking patterns against edge cases; and students learning how regex engines think. Because it runs on the same engine your code uses, it doubles as a precise debugging harness — if a pattern behaves one way here and differently elsewhere, the culprit is almost always a flavor difference between JavaScript and PCRE, Python, or .NET.
Regular expressions are notoriously easy to get subtly wrong — an unescaped special character, a missing anchor, or a greedy quantifier that matches far more than intended. Testing a pattern against realistic sample text before dropping it into production code catches these mistakes early, when they're cheap to fix, rather than after they've silently rejected valid input or let bad input through. This mirrors how engineers validate infrastructure decisions with tools like the Code Complexity Estimator or the API Rate Limit Calculator: verify the behavior before you rely on it.
g flag when you expect more than one match — without it, JavaScript's engine stops after the first match^ and $ so they must match the whole input, not just a substring. or *u flagHow this regex tester turns a pattern and a test string into highlighted matches
RegExp object → executed against the test string at successive positions → yields match(es), each with an index and capture groupsa, b, 1, _ match themselves · Metacharacters: . ^ $ * + ? { } [ ] \ | ( ) carry special meaning · Character classes: [a-z], \d, \w, \s · Quantifiers: * + ? {n,m} (greedy) and *? +? ?? {n,m}? (lazy) · Anchors: ^, $, \b · Groups: (capture), (?:non-capture), (?<name>named) · Alternation: a|bg flag: matches = [...testString.matchAll(regex)] · Without g: matches = regex.exec(testString) ? [m] : []
The tester wraps compilation and matching in a try/catch, so an invalid pattern shows the engine's own error message and a flag field containing anything outside g/i/m/s/u/y — or a repeated flag — is rejected up front. With the g flag, matching uses matchAll(); without it, a single exec() returns only the first match, matching real runtime behavior.
\d matches any digit ([0-9]), \w any word character ([A-Za-z0-9_]), \s any whitespace — with negated forms \D, \W, \S and custom sets like [^...] for everything except a list.
* zero-or-more, + one-or-more, ? zero-or-one, {n,m} between n and m repeats. All are greedy by default; adding a trailing ? (*?, +?, ??) makes them lazy.
^ matches the start and $ the end of the string (with the m flag, of each line). \b matches a word boundary; the sticky y flag forces a match only at the exact current position.
From entering a pattern to reading every match's index and captures
Type or paste your JavaScript regular expression into the Regex Pattern field. The page defaults to \b[A-Za-z]+\b, which matches letter-only words at word boundaries.
Add g to find every match, plus i, m, s, u, or y as your pattern needs. Invalid or duplicate flags show a clear error instead of a crash.
Enter or paste the text you want to search — including multiline content, which the field preserves. The tester re-runs live as you type.
Click "Calculate Matches" (or simply keep typing, since the tool runs on every keystroke) to compile the pattern and scan the string with the native RegExp engine.
Every match is highlighted inline in the test string view. The highlight is built from safe DOM text nodes, so characters like < and > are always shown literally.
The table lists each match's number, zero-based start index, matched text, and capture groups — with (undefined) shown for optional groups that did not participate.
Using the tester's own default scenario — pattern \b[A-Za-z]+\b with the g flag against the default 71-character test string
Suppose you open the regex tester and leave the defaults in place: pattern \b[A-Za-z]+\b, flag g, and the test string "The quick brown fox jumps over the lazy dog. 42 foxes ran past in 2026." — a sentence that deliberately mixes letters, digits, and punctuation to exercise word boundaries.
new RegExp('\\b[A-Za-z]+\\b', 'g') creates a global, case-sensitive, word-boundary-aware matcher.matchAll() walks the string and returns 13 matches. Word boundaries split the sentence so each pure-letter word is its own match.[A-Za-z] — then "foxes" (48), "ran" (54), "past" (58), and "in" (63) match, and "2026" at index 66 is skipped for the same reason.— (no groups).Explanation: The \b anchor is what makes this a clean word matcher. It matches at the transition between a non-word character (space, punctuation, digit) and a word character, so the digit-containing words "42" and "2026" are correctly excluded while the surrounding words are all found. The g flag is essential — without it, only "The" at index 0 would be returned, because JavaScript's engine stops after the first match. The index column gives you the exact positions you'd pass to slice() in production code to locate or transform each match.
What your match count and details table generally imply
| Match Count | What It Generally Means | Recommended Next Step |
|---|---|---|
| 0 matches | The pattern matched nothing in the test string | Check the g flag, anchors (^...$ for whole-input), and whether metacharacters like . or * are escaped |
| 1 match | Without g, this is normal first-match behavior; with g, it means exactly one occurrence exists | Add g if you expected more; verify the details row confirms it's the right occurrence |
| Several matches | The pattern finds multiple occurrences, as intended | Review the indices to confirm matches land in the right positions with no unintended partial hits |
| Many matches | Either a genuinely high occurrence count or a very permissive pattern like . or \w+ | Narrow the pattern with anchors, \b, or more specific character classes |
| Extremely slow / frozen | Possible catastrophic backtracking (ReDoS) | Simplify nested quantifiers and test on shorter inputs before trusting the pattern |
If your pattern shows zero matches: the most common causes are a missing g flag when you expect multiple hits, an anchor mismatch (e.g., ^...$ vs. substring matching), or a metacharacter you meant literally that the engine treats as syntax. Escape it with a backslash.
If every cell in Capture Groups shows —: your pattern has no capturing parentheses, so there is nothing to extract. Add (...) or a named group (?<name>...) around the piece of each match you actually need.
If the details table lists only one match: confirm the g flag is present. This is the single most common reason a pattern "isn't matching" the rest of the text.
This regex tester is an interactive diagnostic tool, not a correctness guarantee. A pattern that matches here still needs validation against your real data — including empty strings, unexpected characters, and malicious input — and a review for catastrophic backtracking before it goes into production code.
Where live-testing a JavaScript regular expression genuinely helps
Draft and verify email, phone, URL, and date patterns against valid and invalid inputs before wiring them into your forms.
Extract timestamps, error codes, IP addresses, and user IDs from log lines to build alerting or dashboards.
Use capture groups to pull structured fields out of unstructured text — invoices, emails, chat transcripts, CSV rows.
Confirm a find-and-replace pattern behaves exactly as intended before running it across a whole codebase or dataset.
Standardize messy user-entered text — spacing, separators, case — and verify the transform against sample rows.
Quickly check edge cases (empty strings, metacharacters, newlines) that a pattern may fail on once it's live.
Whitelist acceptable characters or strip disallowed ones, and confirm the pattern only permits what you allow.
Build the token patterns behind a highlighter or linter, testing how each token class matches real source text.
Verify path, query, and host patterns for web routing or middleware before deploying them.
Parse config blocks, key-value pairs, and delimited records, checking captures against realistic sample files.
Watch greedy vs. lazy quantifiers, anchors, and backtracking in action — ideal for tutorials and workshops.
Re-test old, opaque patterns before touching them, and confirm replacements match the same inputs.
What this regex tester does well, and where it can't replace a full regex toolchain
Battle-tested JavaScript patterns for everyday validation — test each one here before you use it
| Use Case | Common Pattern | What It Matches | Caveats |
|---|---|---|---|
^[\w.+-]+@[\w-]+\.[\w.-]+$ | Standard email form (alice@example.com) | Doesn't enforce full RFC 5322 grammar; good for most form validation | |
| URL | ^https?://[\w.-]+(?:\.[\w.-]+)+[/\w.-]*$ | http/https URLs with host and optional path | Requires a scheme; use a URL parser library for complex cases |
| US Phone | ^\(?\d{3}\)?[-.\s]?\d{3}[-.\s]?\d{4}$ | (555) 123-4567, 555-123-4567, 5551234567 | US-centric and liberal about separators |
| Date (YYYY-MM-DD) | ^\d{4}-\d{2}-\d{2}$ | 2026-08-03 | Accepts invalid dates like 2026-99-99; validate calendar semantics separately |
<.+> matches far too much (the whole <a> <b>), while <.+?> stops at the first >g flag, then wondering why only one match appears^ and $ for whole-string validation, letting the pattern match a substring(a+)+ that can trigger catastrophic backtracking^...$ and test both valid and invalid inputs before deploying.Summary: The Regex Tester lets you validate and refine JavaScript regular expressions against real text — instantly, privately, and with full visibility into indices and captures. Test the pattern, confirm edge cases, then copy it straight into your code. Pair it with the Code Complexity Estimator to keep patterns maintainable, and with the Password Strength Calculator when building validation rules for authentication.
Common questions about regex testing, flags, and JavaScript's RegExp engine
Official documentation to complement this tester — verify syntax and safety guidance before shipping patterns
Explore other developer & tech tools