About this regex tester
Regex Tester
A regex tester lets you try a regular expression against sample text and see every match highlighted instantly, so you can debug the pattern before it goes into your code. Type the pattern, paste the text, and the tool shows matches, capture groups, and errors live as you type.
Developers use it to build and verify patterns for validating emails, parsing log lines, extracting data from documents, and rewriting text with find-and-replace. Writing regex blind is slow: one misplaced quantifier changes what matches, and the bug only surfaces later in production. This tester runs the pattern in your browser using the JavaScript regex engine, with toggles for the standard flags — global, case-insensitive, multiline, dot-all, unicode, and sticky — plus a match list showing each result and its capture groups. Invalid patterns get a plain-English error instead of a silent failure, and a built-in pattern library covers common cases like email, URL, date, and phone formats. Because it runs locally, proprietary log data and customer text never leave your machine.
Testing URL patterns? Encode, decode, or dissect any URL with HexKit’s free URL encoder & decoder.
How to use it
- Type your pattern in the Regular expression field — without the surrounding slashes.
- Toggle the Flags: `g` (global), `i` (ignore case), `m` (multiline), `s` (dot matches newlines), `u` (unicode).
- Paste your sample into the Test string box.
- Read the results: highlighted matches in the text, the Match list with capture groups, and any syntax error explained below the pattern field.
The method behind it
Frequently asked questions
Which regex flavor does this tester use?
JavaScript (ECMA-262), the engine built into every browser. It covers the syntax most web developers need, but it is not identical to PCRE, Python `re`, or .NET — named groups, lookbehind, and flag semantics can differ. If your pattern targets another language, treat a passing test here as a strong signal, then run one final check in that language's own engine.
Why does my pattern match nothing?
The usual suspects: a missing flag (`i` for case-insensitivity, `m` so `^`/`$` work per line), an unescaped special character (`.` matches any character — use `\.` for a literal dot), or the pattern being stricter than the data (for example requiring a TLD your test string lacks). Paste a minimal failing example and toggle flags one at a time; the live highlighting shows the moment it starts matching.
What are capture groups?
Parentheses `(...)` mark a capture group: the engine remembers what that part of the pattern matched, and the tester lists each group's text separately. In code you reference them as `$1`, `$2` in replacements or `match[1]`, `match[2]` in results. Non-capturing groups `(?:...)` group without remembering — use them when you need the grouping but not the value.
How do I validate an email address properly?
Fully validating email per RFC 5322 requires a notoriously long pattern, and even that cannot confirm the address exists. For forms, a pragmatic pattern like the one in the worked example catches typos (missing `@`, missing domain), then send a confirmation email — that is the only real validation. Do not reject unusual-but-valid addresses with an over-strict pattern.
Why did my pattern freeze the page?
Likely catastrophic backtracking: nested or adjacent quantifiers (`(a+)+`, `(.*)*`) force the engine to try an exponential number of combinations on non-matching input. Rewrite to remove the nesting — often `(a+)` alone or a possessive-style formulation fixes it. If the tester stalls, simplify the pattern before using it anywhere important.
Worked example
Pattern: \b[\w.+-]+@[\w-]+\.[\w.]+\b with the g flag.
Test string: Contact us at hello@hexkit.example or support@hexkit.example for help.
The engine finds 2 matches:
hello@hexkit.example— starting at index 14support@hexkit.example— starting at index 37
Reading the pattern: \b anchors at a word boundary, [\w.+-]+ matches the local part (letters, digits, _, ., +, -), @ is literal, [\w-]+ matches the domain, \. the dot, and [\w.]+ the rest. Toggling the i flag off changes nothing here (both addresses are lowercase), but pasting Hello@HexKit.example with i off would break the match — the tester shows that immediately, which is exactly the kind of bug it exists to catch. Every behavior above — flags, character classes, and word boundaries — follows the ECMA-262 specification for JavaScript regular expressions.