We use cookies

We use cookies and similar technologies to enhance your browsing experience, analyze site traffic, and personalize content and ads. By clicking "Accept", you consent to our use of cookies. Learn more in our Privacy Policy.

/.*/

Regex Tester

by Cosmovex

//
Test String
Highlighted Matches
Matches will be highlighted here
Matches
Enter a pattern and test string

Free Regex Tester & Regular Expression Debugger

Test regular expressions online with real-time match highlighting. Supports global, case-insensitive, multiline, and dotall flags. View match groups and named capture groups.

More Developer Tools

View all tools →
±
Diff Checker
Compare two blocks of text
Cron Builder
Build & explain cron expressions
🎨
Color Picker
Pick colors, convert formats
Unix Timestamp
Convert Unix timestamps
{ }
JSON Formatter
Format, validate & explore JSON
YAML Formatter
Lint, format & convert YAML
</>
XML Formatter
Beautify & validate XML
CSV Formatter
View & format CSV tables

Regex Tester is a free tool for building and checking JavaScript regular expressions against your own sample text. You type a pattern and a flags string, paste in some text, and the tool highlights every match as you type. Each capture group is broken out so you can see exactly what your pattern pulled from the text, which is far quicker than guessing in a console and re-running code on each tweak.

It uses the same regex engine that your code will use in the browser, so what you see here is what you get in production. Everything runs in your browser. The patterns and text you paste are never sent to a server or stored anywhere, which makes it safe to test against log lines, config snippets, or anything else you would rather not upload.

How it works

The tool has three inputs: the pattern, the flags, and the test string. As you change any of them, matches update live.

  • Pattern is the regex body, without the surrounding slashes. Write \d{4} rather than /\d{4}/.
  • Flags control matching behaviour. The common ones are g (find all matches, not just the first), i (case-insensitive), m (^ and $ match at line breaks), and s (. also matches newlines).
  • Test string is whatever you want to match against. Paste real data here.

Matches are highlighted inline in the test string. Below that, every match is listed with its start index, the full matched text, and each capture group by number (and by name, if you used named groups). If the pattern is invalid, you get the engine's error message instead of a silent failure, so you know whether the problem is your syntax or your data.

A worked example: pulling fields out of a log line

Say you have lines like:

2026-06-02 14:33:01 [ERROR] payment-service: timeout after 3000ms

You want the date, the level, the service name, and the message. Use named capture groups so the output is readable:

(?<date>\d{4}-\d{2}-\d{2}) \S+ \[(?<level>\w+)\] (?<service>[\w-]+): (?<msg>.+)

With no flags needed for a single line, the match panel shows:

  • date = 2026-06-02
  • level = ERROR
  • service = payment-service
  • msg = timeout after 3000ms

If you paste many lines and add the g and m flags, you'll get one match per line, each with its own groups. This is the fast way to confirm a pattern before dropping it into a parser, because you can see immediately which lines fail to match instead of finding out at runtime.

Common use cases

Regular expressions show up anywhere you need to find or extract structure in text. Typical reasons to reach for this tool:

  • Validation — checking that an email, phone number, postal code, or ID looks right before you trust it.
  • Extraction — pulling values out of logs, CSV-ish data, URLs, or scraped HTML.
  • Search and replace — testing the match half of a find/replace in an editor or codebase before you run it on real files.
  • Routing and parsing — confirming a URL pattern or a config-file rule matches the inputs you expect (and rejects the ones you don't).
  • Learning — experimenting with quantifiers, lookarounds, and groups against live feedback instead of reading reference docs in the abstract.

The live highlighting makes it especially good for the last-mile question that wastes the most time: why isn't this matching the one line I care about?

Greedy vs. lazy quantifiers

The single most common regex surprise is greedy matching. By default, *, +, and ? grab as much as they can. Given the text <a><b> and the pattern <.+>, you might expect <a>, but you get the whole <a><b> because .+ consumes everything up to the last >.

Add a ? after the quantifier to make it lazy, so it takes as little as possible:

<.+?>

Now you get <a> and <b> as separate matches (with the g flag). The same applies to *? and ??.

A related fix is to be specific instead of using .. Matching <[^>]+> says "angle bracket, then one or more non-> characters, then a closing bracket," which is both clearer and faster than relying on laziness. When a pattern matches too much, ask whether . is the culprit and whether a negated character class would describe your intent better.

Flags and gotchas worth knowing

A few behaviours trip people up:

  • ^ and $ are line-aware only with m. Without the m flag, ^ means start of the whole string and $ means the end. Add m to anchor per line.
  • . skips newlines unless you set s. If your data spans lines and a .+ stops short, the s (dotAll) flag is usually the fix.
  • The g flag changes more than the count. It also drives match position across calls in code via lastIndex. In this tool you simply see all matches, but remember that a g-flagged regex object is stateful in real JavaScript.
  • Backslashes need care in source code. Here you type the raw pattern, but when you copy it into a JavaScript string (rather than a /.../ literal), you must double the backslashes: \d becomes "\\d".
  • Escape special characters when you mean them literally. A dot is \., a question mark is \?, and so on.

Tips

  • Add the `g` flag whenever you want to see every match, not just the first one.
  • When a pattern grabs too much, try a lazy quantifier (`+?`, `*?`) or a negated class like `[^>]+` before reaching for anything fancier.
  • Use named groups `(?<name>...)` so the match output is self-documenting instead of just numbered.
  • Test against your worst-case input, including empty lines and lines that should NOT match, to catch false positives.
  • Anchor with `^` and `$` plus the `m` flag when validating one value per line.
  • Prefer specific character classes over `.` for both correctness and speed on large inputs.

How to use Regex Tester

  1. 1Enter your regular expression and flags.
  2. 2Paste the text to test against.
  3. 3Matches are highlighted live with capture groups listed.
  4. 4Refine the pattern until it matches what you need — all locally.

Frequently asked questions

Do I include the slashes when typing my pattern?

No. Type only the pattern body, like `\d{4}-\d{2}`, and put flags in the separate flags field. The surrounding `/.../ ` slashes are JavaScript literal syntax, not part of the pattern itself.

Why does my pattern only match the first occurrence?

You need the global flag. Add `g` to the flags field and every match in the test string will be found and highlighted.

How do I make matches case-insensitive?

Add the `i` flag. For example, the pattern `error` with flag `i` will match `Error`, `ERROR`, and `error`.

Why doesn't `^` match the start of each line?

By default `^` and `$` match only the start and end of the entire string. Add the `m` (multiline) flag to make them match at the start and end of each line.

My `.+` stops at a line break. How do I match across lines?

The dot does not match newline characters unless you enable dotAll mode. Add the `s` flag so `.` also matches line breaks.

Will the regex I test here behave the same in my JavaScript code?

Yes. The tool uses the browser's built-in regular expression engine, the same one your JavaScript runs on. One caveat: if you put the pattern in a JS string instead of a `/.../ ` literal, double the backslashes (`\d` becomes `"\\d"`).

Is my data sent anywhere?

No. The pattern and test text are processed entirely in your browser. Nothing is uploaded or stored, so it is safe to paste logs or other sensitive text.

How do I extract specific parts of a match instead of the whole thing?

Wrap the parts you want in parentheses to create capture groups, and they appear separately in the match output. Use named groups like `(?<year>\d{4})` to label them for readability.

← All toolsRead our guides →