# Regex Tester Guide: Patterns, Flags, and Capture Groups Regular expressions are one of those tools every developer eventually has to learn. They show up in form validation, log parsing, search-and-replace tasks, and countless one-off scripts. But regex is also infamous for being write-only - even the author can struggle to read it a week later. A good regex tester turns that opaque string into something you can actually see working, which makes both learning and debugging dramatically easier. This guide walks through how to think about JavaScript regex pragmatically, how the flags actually behave, what capture groups give you, and the pitfalls that bite people most often. ## Why a Browser Regex Tester Most regex bugs come from a mismatch between what you *think* the pattern matches and what it *actually* matches. A browser-based tester closes that gap immediately. You paste sample text, type a pattern, and watch matches highlight live as you type. No build step, no console.log noise, no network round-trips that could leak sensitive data. The other reason matters even more for learning: a tester gives you instant feedback on each character you type. You can see exactly when adding `?` flips a quantifier from greedy to lazy, or when `\\b` does the right thing at a word boundary. That tight feedback loop is what turns regex from intimidating syntax into something you can reason about. ## Pattern + Flags Anatomy A JavaScript regex has two parts: the pattern itself and an optional set of flags. In source code you'll see them written as `/pattern/flags`, but in a tester you usually enter them separately. The five flags you'll use most often: - **`g` (global)** - Without `g`, methods like `String.matchAll` and the tester's "find all" loop will only return the first match. Almost every interactive testing UI keeps `g` on by default for that reason. - **`i` (ignore case)** - Lets `[A-Z]` match lowercase letters and vice versa. Important for matching things like email domains or HTTP headers. - **`m` (multiline)** - Changes what `^` and `$` mean. By default they anchor to the start/end of the entire string; with `m` they anchor to each line. - **`s` (dotAll)** - Without it, `.` matches any character *except* newline. With `s`, `.` matches every character including newlines, which is useful when matching across lines. - **`u` (unicode)** - Enables proper handling of Unicode code points, including astral characters like emoji and `\\p{...}` property escapes. Highly recommended whenever you might encounter non-ASCII input. The combinations matter. `gi` is what you usually want for case-insensitive search-and-replace. `gm` is right for finding line-by-line matches across a multi-line string. `gus` gives you Unicode-aware "match anything" behavior. ## Capture Groups & Named Groups Capture groups are how you extract structure from a match, not just check whether the pattern matches. A plain parenthesis `(...)` creates a numbered capture group. The first one is `$1`, the second is `$2`, and so on. So `(\\d{4})-(\\d{2})-(\\d{2})` against `2026-04-25` gives you `$1 = "2026"`, `$2 = "04"`, `$3 = "25"`. Most regex testers display these as a list under each match. A non-capturing group `(?:...)` looks the same but doesn't create a numbered slot. Use it when you need to apply a quantifier or alternation to part of your pattern but don't care about extracting the value: `(?:https?):\\/\\/...`. This keeps your numbered groups clean and your code more readable. Named groups `(?...)` give your captures real names instead of indices. So `(?\\d{4})-(?\\d{2})-(?\\d{2})` lets you access `match.groups.year` directly. This is much more maintainable when patterns evolve - reordering groups doesn't break call-sites that reference names. In our regex tester, both numbered and named groups are listed under each match, so you can confirm they capture exactly what you expect before pasting the pattern into your code. ## Common Pitfalls ### Forgetting to escape special characters Characters like `.`, `?`, `+`, `*`, `(`, `)`, `[`, `]`, `{`, `}`, `|`, `^`, `$`, `\\`, and `/` have special meanings in regex. If you want them to match literally, escape them with a backslash. The classic mistake is writing `example.com` and being surprised it matches `examplexcom`. Use `example\\.com` instead. ### Greedy vs lazy quantifiers By default, quantifiers like `*`, `+`, and `{n,m}` are greedy - they match as much as possible. So `<.+>` against `` matches the whole ``, not just ``. Add `?` after the quantifier to make it lazy: `<.+?>` matches `` and `` separately. Lazy quantifiers are the right tool for "smallest thing between two delimiters" patterns. ### Zero-width matches and infinite loops A pattern like `a*` can match zero characters at every position, which means a naive "find next match" loop can spin forever. Most engines (and our tester) skip empty matches automatically, but if you're writing your own loop you need to advance the cursor manually after a zero-width hit. Always end quantifiers with at least one mandatory character if you can. ### Unicode and the `u` flag Without `u`, JavaScript treats astral characters (like most emoji) as two separate code units, which breaks character classes and quantifiers in surprising ways. `[a-z]` won't match accented letters, and `\\w` is restricted to ASCII. If your input might contain non-English text, turn on `u` and consider `\\p{L}` (any letter) instead of `\\w`. ## Try It Open our [regex tester](/en/dev/regex-tester) and paste any text you want to match against. Toggle flags, try the email or UUID presets, and watch matches and capture groups update live. Everything runs in your browser - no input ever leaves your machine.