Regex Tester
Test a regular expression against your own text and see every match with its position and capture groups. Switch to replace mode to rewrite the text, or
Type a pattern, paste your text and see every match highlighted with its position and capture groups. Switch to replace mode to rewrite the text with a substitution, or to extract mode to pull one capture group out line by line - the fastest way to check a pattern before it goes into code.
The engine is the JavaScript regular expression flavour that browsers use, so the result matches what you would get in Node or in the browser console, including named groups, lookahead and lazy quantifiers. Flags for global, case-insensitive, multi-line, dot-all and unicode matching are available, and a runaway pattern is stopped instead of freezing the tab.
How to test a regular expression
Enter the pattern and set the flags
Paste the text to test against
Read the matches, or use replace and extract mode
FAQ
Which regex flavour is used?
JavaScript (ECMAScript), the same engine as your browser and Node.js. Patterns written for PCRE, Python or Java may need small changes - possessive quantifiers and recursion are not part of this flavour.
Why did my pattern freeze or stop?
Catastrophic backtracking, usually from nested quantifiers such as (a+)+ against a long non-matching string. The tool stops after a fixed number of iterations to protect the tab; simplify the pattern or anchor it.
How do I replace text?
Switch to replace mode and enter the substitution. $1, $2 or $<name> insert capture groups, so you can reformat dates, swap fields or clean up logs.
What does extract mode do?
It outputs one capture group per line instead of the whole match, which is exactly what you want when scraping email addresses, URLs or IDs out of a blob of text.
Do newlines work in my pattern?
Only with the multi-line or dot-all flags. By default . does not match a newline, which is a common reason a pattern works on one line but fails on a paragraph.
Is my text uploaded?
No, matching runs locally - useful when the text contains real log data or customer information.
At a glance
| Input | text |
|---|---|
| Multiple files | No |
| Where it runs | In your browser - files are never uploaded |
| Works offline | Yes — once the page has loaded |
| Price | Free, no sign-up, no watermark |
Where conversions quietly break
Most conversion bugs are not about syntax, they are about meaning. A CSV column of postcodes loses its leading zeros the moment a spreadsheet guesses it is a number; a long ID exceeds floating-point precision; dates change meaning depending on whether they are day-first or month-first. JSON keys are unordered but arrays are not, and a tool that sorts keys changes nothing while one that sorts arrays changes the data. Unicode is another trap: text can arrive as UTF-8, UTF-16 or with a byte-order mark, and a decoder that guesses wrong turns accented characters into mojibake. Before trusting any conversion, spot-check the first and last row, any field with leading zeros, and any field containing quotes, commas or newlines.
Choosing a data format
JSON is the default for anything an API returns or a program reads: it handles nested structures, numbers, booleans and null naturally, and every language parses it. CSV is smaller and opens straight into a spreadsheet, but it has no way to express nesting and no shared standard for the delimiter, quoting or character set - which is exactly where conversions go wrong. XML is verbose but carries attributes, mixed content and schemas, so it still dominates document formats and legacy integrations. YAML is the most readable for configuration but is whitespace-sensitive and has surprising type coercion ("no" becoming false, a version like 1.10 becoming 1.1). Pick the format the consuming tool prefers rather than the one that looks nicest.