Regex Tester

Test regular expressions against sample text with live matches.

This tool runs entirely in your browser. Your data is never uploaded, never stored, and never leaves your device.

Runs a regular expression against sample text and shows every match highlighted in place, then lists each one with its index and any captured groups.

How to use it

1Enter the pattern without delimiters — \d+ rather than /\d+/, since surrounding slashes would be treated as literal characters.
2Adjust the flags field: i for case-insensitive, m for multiline anchors, s for dot-matches-newline.
3Paste the test string; highlighting and the match list update on every keystroke.

Example

Input: Pattern \d+ against a1b22c333
Output: 3 matches — 1 at index 1, 22 at index 3, 333 at index 6

The g flag is appended for you even if you clear the flags box, so you always see every match rather than only the first. Matches are numbered from 0, and capture groups appear beneath each one as [1], [2] and so on.

What happens to your data

The pattern is compiled with the browser's own RegExp engine inside your tab, so neither it nor your test text is uploaded. One consequence worth knowing: a heavily backtracking pattern burns your CPU and can briefly freeze the page, because there is no server doing the work.

Last updated August 2026

Test and debug regular expressions against your own sample text with live, highlighted matches. Regex is powerful but easy to get subtly wrong; seeing exactly what a pattern matches (and what it doesn't) as you type turns guesswork into certainty.

Write a pattern, paste sample input, and watch matches and capture groups update instantly.

Decide first whether you are validating or scanning, because it changes the pattern. Validation asks whether a whole string is a postcode; scanning asks where the postcodes are inside a paragraph. An unanchored pattern will happily report a match sitting inside a longer, invalid string, which is how a field that should reject 12 Downing Street ends up accepting it. Anchor with ^ and $ when the answer has to be yes or no, and leave the anchors off when you want every occurrence.

The second thing to settle is what your pattern actually is, as opposed to how your source file writes it. A pattern lifted out of Python, Java or JSON carries that language's own escaping, so a doubled backslash in the file is a single one to the engine; one lifted out of JavaScript source arrives wrapped in slashes with its flags on the end, and none of that belongs in the pattern box. Paste what the engine sees, or lose ten minutes to a backslash.

How it works

Toolvore evaluates your regular expression against your text in the browser using the native JavaScript regex engine. Your patterns and test data never leave your device. Whatever you type in the flags box, a g is added if it is missing, so the results are always the full scan rather than the first hit — the single-match behaviour of test and exec, and anything that turns on lastIndex, cannot be reproduced here. Two oddities follow from that. A pattern able to match nothing, such as d* or , produces an empty match at every position, and the highlighter stops at the first of them, so the count underneath can read forty while the text above shows no colour at all. Capture groups are listed by number, taken straight off the match array: a named group appears under its number rather than its name, non-capturing groups never appear, and a group that took no part in the match reads undefined rather than empty.

Common use cases

Building and debugging validation patterns (emails, phone numbers, slugs)
Extracting data from logs or text with capture groups
Testing search-and-replace patterns before using them in code
Learning regex behaviour with immediate feedback
Checking whether a pattern written for another language behaves the same way in JavaScript
Working out why a validation rule accepts a string it should reject

Frequently asked questions

Which regex flavour does it use?＋

JavaScript (ECMAScript) regular expressions, which are close to PCRE for most common patterns.

Are my patterns and text uploaded?＋

No — everything runs locally in your browser.

Why isn't my pattern matching?＋

Common causes are missing flags (like case-insensitive), unescaped special characters, or greedy vs lazy quantifiers. Adjust and watch the live results.

Why does my regex work in Python or grep but not in JavaScript?＋

Regular expressions are a family of dialects, and this page speaks the JavaScript one. Three gaps catch people moving a pattern across. There are no inline modifiers, so a leading (?i) is a syntax error rather than a switch, and case-insensitivity has to go in the flags. There is no verbose mode, so a pattern broken over several commented lines must be flattened into one string. And there are no atomic groups or possessive quantifiers, the usual cure for a slow pattern elsewhere. One thing runs the other way: JavaScript allows a variable-length lookbehind, so (?<=\w+:) is legal here and rejected by Python's re, which insists on a fixed width.

What is catastrophic backtracking, and how do I spot it before it bites?＋

It is the failure mode where a harmless-looking pattern takes exponential time. The shape to recognise is a repeat nested inside another repeat over the same characters — (a+)+ or (\s*\w+)* — fed a subject that nearly matches and then fails at the end. Before reporting no match, the engine tries every way of dividing that run between the inner repeat and the outer one, so a couple of dozen extra characters take the runtime from milliseconds to minutes, with nothing left on a single-threaded page to click. The cure is to make the division unambiguous: one character class doing the repeating rather than a group inside a group. This page refuses that shape outright once the test string passes 200 characters, and the check is blunt — plain patterns like [a-z]+ are caught alongside the dangerous ones.

How do I make a pattern work across several lines of text?＋

Two different flags, and the wrong one gets reached for constantly. The m flag lets nothing match a newline; all it does is redefine ^ and $ to mean the start and end of each line rather than of the whole string. The s flag, dotAll, is the one that lets a dot cross a line break — without it, a dot matches every character except a line terminator. Neither is on unless you type it, since the flags box starts with g alone. Mind your line endings too: text pasted from Windows carries a carriage return before each newline, and ECMAScript treats that as a line terminator, so a class written as anything-except-newline swallows it and leaves an invisible character in your match.

Why doesn't \d or \w match accented letters or non-Latin digits?＋

Because those shorthands are defined on ASCII and nothing else. In JavaScript, \d is exactly the digits 0 to 9, \w is exactly the Latin letters, the digits and the underscore, and \b is derived from \w — so the boundaries it finds land in the middle of a word like naïve rather than around it. Unicode property escapes are the proper fix, \p{L} for any letter or \p{Nd} for any decimal digit, but they only carry that meaning with the u or v flag on. Here is the trap: without the flag the escape is not an error. It degrades to a literal p followed by a brace, so the pattern quietly matches nothing and reports nothing wrong.

What is the correct regex for validating an email address?＋

There isn't one worth writing, and the effort is misdirected. RFC 5322 permits quoted local parts, bracketed comments and folded whitespace; the well-known conformant expressions run to thousands of characters and still accept addresses no mail server would deliver to. A grammar check tells you a string is well formed, never that somebody reads it. The workable approach is a deliberately loose test — a non-empty part before a single @, a domain with a dot in it, no spaces — followed by a confirmation message, which is the only check that proves anything. If you want a written-down grammar rather than your own invention, the HTML standard publishes the pattern browsers use behind an email input.

Can a regular expression parse HTML, JSON or nested brackets?＋

Not in the general case, and the reason is structural rather than a lack of cleverness. A regular expression has no counter, so it cannot tell which closing bracket pairs with which opening one at arbitrary depth, and the same limit rules out matching a tag against its own end tag through nested copies of itself. Some engines bolt something on — recursion in PCRE, balancing groups in .NET — but ECMAScript has neither, so a JavaScript pattern cannot manage it at any length. Regex suits a flat, predictable line: a log format you control, an attribute you know appears once. Once the input can nest or quote its own delimiters, use a parser and keep the pattern for the leaf values.