Guides · Updated 2026-10-23

Online regex tester and builder: write regular expressions that actually work

Nobody writes a correct regular expression on the first try — not juniors, not staff engineers. The difference is that experienced developers never trust a regex they haven't watched run against real input. That is the whole job of an online regex tester: type the pattern, type the text, and see every match and capture group highlighted as you type.

This guide shows how to build a regex incrementally instead of guessing, what each flag actually does, and the handful of patterns — emails, mobile numbers, PIN codes, GSTIN — that cover most day-to-day validation. Follow along in the free online regex tester: it runs entirely in your browser, nothing is uploaded, and there is no sign-up.

How an online regex tester works

A regex tester is a tight feedback loop. You give it two things — a pattern and a test string — and it gives you back three:

Every match, highlighted in place, so you see at a glance what the pattern grabbed and, just as importantly, what it missed.
Capture groups per match — both numbered groups like (\d{4}) and named ones like (?<year>\d{4}) — which is what you'll actually extract in code.
Clear errors for bad patterns, like an unclosed bracket or a stray quantifier, instead of a silent zero-matches.

The DoAide Code regex tester uses the JavaScript regex engine, re-running on every keystroke. Since everything is computed in the page, you can safely paste real log lines or data samples — they never leave your machine.

Building a regex step by step (the builder mindset)

The reliable way to write a regex is to grow it one piece at a time with the tester open. Say you need to pull dates like 23/10/2026 out of messy text:

Start with the literal core: / matches itself, so begin with \d/\d and confirm it highlights something.
Add quantifiers: \d{2}/\d{2}/\d{4} — two digits, two digits, four digits. Check it against a real sample.
Add capture groups for the parts you need: (\d{2})/(\d{2})/(\d{4}), or named groups (?<day>\d{2})/(?<month>\d{2})/(?<year>\d{4}) so your code reads match.groups.year instead of match[3].
Test the negatives: paste text that should not match — 123/45/678901, a phone number, an IP address — and tighten with boundaries: \b(\d{2})/(\d{2})/(\d{4})\b.
Only then copy it into your code, flags included.

Each step is a five-second check in the tester. Skipping those checks is how a regex that "looked right" ends up matching half your log file.

Common patterns: email, mobile numbers, PIN codes, GSTIN

A starter set worth keeping (test each against your own data before shipping):

What	Pattern	Notes
Email (pragmatic)	`[\w.+-]+@[\w-]+\.[\w.]{2,}`	Catches real addresses; full RFC-compliant email regexes are a trap — validate by sending a mail.
Indian mobile number	`\b[6-9]\d{9}\b`	Ten digits starting 6–9; add `(?:\+91[ -]?)?` in front to allow a +91 prefix.
PIN code	`\b[1-9]\d{5}\b`	Six digits, no leading zero.
GSTIN	`\b\d{2}[A-Z]{5}\d{4}[A-Z]\d[A-Z]\d\b`	State code + PAN + entity, Z is literal in position 14 for most registrations — this shape-check catches typos, not validity.
ISO date	`\b\d{4}-\d{2}-\d{2}\b`	Shape only; 2026-13-45 still matches. Parse to validate.
Number with decimals	`-?\d+(?:\.\d+)?`	`(?: )` groups without capturing.

Paste any of these into the regex tester with a page of your real data and watch what over- and under-matches before trusting it.

Flags: what g, i, m and s actually change

g (global): find every match, not just the first. Almost always what you want in a tester; in code, required for matchAll and replace-all.
i (ignore case): error also matches Error and ERROR — the flag to reach for when scanning logs.
m (multiline): ^ and $ anchor to each line instead of the whole string. Essential when testing against multi-line pastes.
s (dotall): . also matches newlines, so start.*end can span lines.

A classic confusion: with multiline text and no m, ^\w+ matches only the very first word of the paste. Toggle flags in the tester and watch the highlights move — it teaches the difference faster than any cheat sheet.

The regex mistakes that bite in production

Greedy wildcards: ".*" grabs from the first quote to the last quote on the line. Use the lazy form ".*?" or, better, "[^"]*".
Unescaped special characters: ., +, (, [ and friends mean something. Matching a literal dot in app.doaide.com needs \. — otherwise appXdoaide matches too.
Missing anchors in validation: \d{6} happily finds six digits inside a 16-digit number. Validation patterns should be anchored: ^\d{6}$.
Catastrophic backtracking: nested quantifiers like (a+)+$ can take seconds on a 40-character non-matching input — a real denial-of-service vector if user input hits that regex on your server.
Using regex where a parser belongs: HTML, JSON and SQL are not regular languages. Extract a quick value, fine; parse structure, use a parser — or the JSON validator for JSON.

If a hairy regex in a codebase resists understanding, paste the surrounding function into Explain Code and get the pattern translated into English, piece by piece.

Test your regex free — live highlighting

Frequently asked questions

What is the best free online regex tester?

A good regex tester highlights every match and capture group live as you type, explains pattern errors, supports the g/i/m/s flags, and runs in your browser so your test data is never uploaded. The DoAide Code regex tester at code.doaide.com/tools/regex-tester does all of this free, with no sign-up.

Which regex engine does an online tester use?

The DoAide Code tester runs your pattern on the browser's own JavaScript (ECMAScript) engine. JavaScript regex covers the common syntax shared with Python and Java; a few advanced features differ (for example Python's re.VERBOSE or possessive quantifiers), so always re-test in your target language for exotic patterns.

How do I test a regex with capture groups?

Wrap the parts you want to extract in parentheses, or use named groups like (?<year>\d{4}). The tester lists each match with its numbered and named groups, so you can confirm exactly what match.groups.year will contain in your code.

Why does my regex match too much?

Usually a greedy quantifier: .* expands to the longest possible match. Make it lazy with .*? or replace the dot with a negated class like [^"]* that cannot cross the closing delimiter. Testing against realistic multi-line input in a tester shows the over-match immediately.

Is it safe to paste real data into an online regex tester?

In the DoAide Code tester, yes in the technical sense: matching runs entirely in the page and nothing is sent to a server. Still, mask customer personal data out of habit before pasting it anywhere — a few X characters rarely change whether the pattern works.