JavaScript Regex Examples: Practical Patterns to Test Before You Ship

Regular expressions are compact, which makes them powerful and easy to get subtly wrong. The safest habit is to test a pattern against both inputs you expect to match and inputs you expect to reject.

Use the JavaScript regex tester to keep the pattern, flags, source text, matches, capture groups, and replacement result in one place.

Start with a narrow purpose

Do not begin with a giant pattern that tries to validate an entire business rule. First decide what the expression needs to do: extract IDs from a log, find repeated whitespace, validate a simple format, or replace a known token.

For example, this pattern extracts dates in YYYY-MM-DD form:

const dates = text.match(/\b\d{4}-\d{2}-\d{2}\b/g);

It checks the shape of the text, not whether every calendar date is real. That distinction matters. A regex is often best used for syntax; use normal code for rules that require arithmetic or outside knowledge.

Test the flags as well as the pattern

In JavaScript, flags change behavior:

g finds every match instead of stopping at the first.
i ignores letter case.
m changes how ^ and $ behave across lines.
s lets . match line breaks.

A pattern that works in one test can fail in production because a flag was missing. Add multiline input and edge cases to the tester before copying the expression into your project.

Avoid expensive patterns on untrusted input

Nested, ambiguous quantifiers can trigger excessive backtracking. A pattern such as (a+)+$ can become slow on a long non-matching string. Keep alternatives explicit, limit input length where possible, and test bad cases as well as happy paths.

When a pattern becomes hard to explain, split the work into a small regex plus ordinary JavaScript. The code will usually be easier to maintain and safer to change later.

FAQ

What do the g, i, m, and s flags do in JavaScript regex?

g makes the pattern find every match instead of stopping at the first, i ignores letter case, m makes ^ and $ match at line boundaries instead of string boundaries, and s lets . match newline characters.

Why does my regex work in testing but fail in production?

The usual suspects: a missing flag (especially g), input the test never covered (multiline text, unicode, empty strings), or catastrophic backtracking on a long real-world input. Test against production-shaped data, not just the happy path.

What is catastrophic backtracking?

Nested quantifiers like (a+)+$ force the regex engine to try exponentially many ways to split a string when a match fails. A pattern that runs instantly on short input can freeze a Node.js server on a long crafted one. Keep quantifiers unambiguous and cap input length.

Can regex validate emails and dates?

Regex can check syntax — that something looks like an email or a YYYY-MM-DD date — but not whether the address exists or the calendar date is real. Use regex for shape, and real code or confirmation emails for truth.