Regex Tester

Flags modify how the pattern behaves, and they are toggleable here with a click so you can see exactly what each one does. Global makes the search continue past the first match and find them all. Without it, you get one match and stop, which surprises anyone who expected everything.

Case-insensitive does what it says, and it is worth toggling on a moment before deciding a pattern does not work, since half of the cases where a pattern matches nothing are a case mismatch. Multiline changes what the anchors mean: normally caret and dollar match only at the very start and end of the whole string, but with multiline they match at every line break too, which is what you want when processing text line by line.

Dotall lets the dot match newlines, which it otherwise refuses to do. If your pattern was meant to span lines and only matched the first one, this is the flag that fixes it. Toggle each flag and watch the highlight change: it teaches what a paragraph of documentation cannot.

Capture groups are the brackets in your pattern, and they are how you pull pieces out of a match. The groups panel here shows every group for every match, so you can see your pattern working at the level of detail that matters.

The thing to know about groups is that they are numbered by the order of their opening brackets, left to right, across the whole pattern. Which means adding a group in the middle silently renumbers every group after it. If your code references group 3, and you add a bracket before it, group 3 is now something else, and nothing warns you. This is one of the classic silent bugs of regex work, and seeing the groups laid out per match makes it visible instead of invisible.

Named groups fix the problem: a group written with a name keeps its identity no matter what you add around it. Non-capturing groups let you group for logic, like applying a quantifier to a sequence, without consuming a number. Both are worth reaching for whenever a pattern grows past a couple of brackets.

The most common regex failure is the quiet one: the pattern runs, matches nothing, and the code proceeds as if the text was absent. The usual cause is an unescaped special character. Dot, plus, question mark, brackets, braces, and pipes all have meaning in a pattern, and to match one literally you need a backslash in front of it.

The second most common is a flag issue: the match needed the global flag, or the case-insensitive one, or the pattern anchored at line starts when the string was one long line. The third is an anchor mismatch: the pattern expects the text to start with something, and the text has a space or a prefix before it.

This tester makes all three diagnoses fast. No highlight means no match, so the feedback is instant. Remove the anchors and see the match appear: it was an anchor problem. Toggle the flags: it was a flag problem. Add the backslash: the dot is a literal dot again. Working with a live highlight turns debugging a pattern from a guessing game into a search you can see.

This regex tester online runs your pattern with the JavaScript engine built into your browser, the same one used by Node.js and by any validation or search code running on a web page. What matches here is exactly what matches in JavaScript.

Most everyday syntax is shared across languages: character classes, quantifiers, anchors, groups, alternation and lookahead behave the same in JavaScript, Python, Java, C# and PCRE. The differences show up at the edges. Python writes named groups as (?P<name>...), while JavaScript and .NET use (?<name>...). Possessive quantifiers and atomic groups exist in Java and PCRE but not in JavaScript. Inline flags such as (?i) at the start of a pattern work in Python and PCRE but not in older JavaScript. Test with the engine your code will actually run, or check the documentation for anything beyond the common core.