Test a regular expression

Test JavaScript regular expressions against representative text without uploading source data. Enter a pattern separately from its flags, then inspect matched values, source indexes, and capture groups. Global patterns return up to the first 1,000 matches; non-global patterns return the first match, mirroring JavaScript behavior.

Regular expressions can suffer catastrophic backtracking. FileGizmo runs every test in a disposable browser worker and terminates it after 750 milliseconds, preventing a pathological pattern from permanently freezing the interface. The timeout is a safety boundary, not proof that a pattern is efficient against every production input.

Syntax follows the current browser’s JavaScript RegExp implementation, including supported Unicode features and flags. Patterns and test content remain local and are not saved. Validate important expressions with diverse realistic cases, edge conditions, and performance tests before using them for security checks, routing, validation, or processing untrusted large inputs.

Patterns run inside a disposable worker with a time limit. A regular expression that backtracks catastrophically, the classic nested-quantifier case such as (a+)+b against a long run of a, will hang a normal page until the tab is killed. Here the worker is stopped and discarded, the tab stays responsive, and you are told the pattern took too long rather than being left to guess.

Matches are shown with their position and their capture groups, so you can see which part of the pattern claimed which part of the text. Named groups appear under their names. When a pattern matches nothing, the result says so explicitly instead of leaving an empty box that could equally mean the tool failed.

This is the JavaScript flavour, which matters more often than people expect. Lookbehind, named groups, and the u and s flags behave as they do in a browser and in Node, not as they do in PCRE, Python, or Go. A pattern verified here will behave the same way in the code you paste it into, which is the entire point of testing it somewhere first.

The usual reason to reach for this is a pattern that works on three examples and fails on the fourth. Paste the real text, including the awkward line that broke it, and step through what the pattern actually matched rather than what it was meant to match. Log lines, addresses, and anything containing a stray delimiter are where assumptions usually collapse.

Nothing is uploaded, which is the difference that matters when the text you are testing against is a production log or a customer record. Other testers send both the pattern and the sample to a server to evaluate. Here the worker runs on your machine, so a sample containing real data never becomes someone else’s problem.