See matches and line-by-line results before using a pattern in an application.
Understand the format
A pattern is only as good as the examples it has been tried against, including the ones that must fail. This tester shows both the matches found and a pass or fail verdict for each line.
The Matches list runs the expression globally across the whole sample and shows every substring it found, which is the right view when you are extracting data from logs or free text. The Line checks list runs the pattern once per line and reports whether that line matched, which is the right view when the pattern is a field validator.
The distinction matters because an unanchored pattern can produce a match on almost every line while still failing as a validator. Reading both views together is what exposes that: many matches but a line you expected to fail marked as matched means the pattern needs anchors.
The g flag finds every match rather than stopping at the first. The i flag ignores case. The m flag makes ^ and $ match at each line boundary instead of only at the start and end of the whole input, which is exactly what you want when testing a multi-line sample. The s flag lets a dot match newlines, and u enables Unicode-aware matching including property escapes.
Because m changes what anchors mean, a pattern that appears to work on a multi-line sample can behave completely differently against a single value in production. Always test with the same flags the application will use.
Step by step
Patterns and sample text are evaluated by the browser regex engine in the page, so log excerpts used as samples never leave your machine.
Worked examples
Input
pattern ^[a-z0-9_-]+$ with flags gm against three lines
Result
softkey-tools -> Match release_2026 -> Match invalid value -> No match
The third line fails on the space, which is the intended behaviour. Without the anchors it would match the fragment "invalid" and pass.
Input
pattern <.+> against <a><b>, then <.+?>
Result
<a><b> vs <a> and <b>
The greedy .+ consumes as much as possible and returns one long match. Adding ? makes it lazy, so each tag is matched separately.
Reference
| Flag | Name | Effect |
|---|---|---|
| g | Global | Returns every match instead of only the first. |
| i | Ignore case | Letter comparisons become case-insensitive. |
| m | Multiline | Makes ^ and $ match at each line break. |
| s | Dot all | Allows the dot to match newline characters. |
| u | Unicode | Enables code-point matching and \p{...} property escapes. |
| y | Sticky | Matches only at the current index, used for tokenisers. |
Practical Guide
Troubleshooting
FAQ
No. Enter the pattern body only and put the flags in the flags field, the same way most languages construct a regex from a string.
The pattern is probably unanchored, so it matched a fragment. Add ^ and $ to require the whole line to match.
A pattern whose alternatives multiply on a non-matching input, so the engine explores an exponential number of paths. It can freeze a server thread on a single request, which is why untrusted input needs both a length limit and a reviewed pattern.
Yes, the browser engine. Basic syntax matches other ecosystems, but lookbehind, named groups, and Unicode handling vary, so confirm in your own runtime.
The Matches list shows full matches. To inspect individual groups, temporarily reduce the pattern to the group you care about, or test it in the runtime that will consume the captures.
Go deeper
