How to Test Regular Expressions Before You Ship Them

Regex Testing on DevOkk.com is a pattern, a fixture, and a highlight. No account. This page is how to test so you are not surprised by greed, flags, or a flavor mismatch with your runtime.

Shipping an untested pattern is a product decision

Regex shows up in validation, log scraping, redirects, and “quick” migrations. It fails in public: a sign-up form that rejects a valid plus-address, a redaction job that leaves the token on the next line, a rewrite rule that swallows a path.

People paste a pattern into the first tester a search result offers because the editor’s regex engine is unpleasant, or because they want highlights. Many of those testers are fine for dummy data. They are a bad place for a production log line that includes an email and a session id. A browser-local tester is the better default: the fixture stays in the tab. You still choose what you paste.

If you already have the pattern and three examples, open the tool. If you have been changing slashes until CI went green, stay for the test-set habit.

A small fixture beats a clever pattern

Write the examples first, in plain English.

• Must match: the strings you are paid to accept
• Must not match: the strings that would be a defect if they passed
• Near miss: extra space, wrong delimiter, Unicode lookalike, trailing newline
• Empty and huge: "" and a 10 KB paste

Then write the pattern to satisfy the list, not the other way around. If you cannot list a near miss, you do not understand the input yet.

Keep fixtures in the repo next to the code when the pattern is load-bearing. A browser tab is for discovery. The checked-in examples are for the next person who “improves” the regex.

Normalize case in the fixture if the rule is case-insensitive - or do not, and use a flag on purpose. Silent case folding is how ID and id become the same thing in one environment and not another. If you need a bulk case pass on sample identifiers, that is Case Converter, not a regex with twenty character classes. The longer case map is How to Convert Text Case.

Run it against the strings you will actually see

Open Regex Testing. Paste the pattern. Paste a fixture that looks like production, not like foo and bar, unless the input really is foo and bar.

Read the matches, not just the green “it matched.” Capture groups are where off-by-one lives. A pattern that matches the whole line and captures nothing is a different tool than a pattern that captures the invoice number.

Flags:

• i - ignore case. Useful; also the way you match istanbul and regret it in another locale.
• m - ^ and $ apply per line. Forgetting it is why ^ERROR misses the second line of a blob.
• s - dot matches newline, in flavors that have it. Without it, .* stops at the first break and you think the file is “wrong.”
• g - find all, in JavaScript. Without it you get the first hit and assume there is one.

Greed: .* will eat until the last chance to satisfy the rest of the pattern. .*? is not always the fix; sometimes you need a negated class ([^,]+) so the engine cannot cross a delimiter. If you are reaching for nested .*, you may be parsing a language. Stop.

Catastrophic backtracking is real. A pattern like (a+)+b on a long string of as can lock a tab. If the tester hangs, the production process will too. Rewrite with clearer bounds, or do not use regex for that input.

What a browser tester will not catch

Flavor. JavaScript regex is not PCRE and not Python. Lookbehind, named groups, and POSIX classes may exist in one place and throw in another. After the tab looks good, run the same fixture in the language’s REPL or unit test.

Encoding. A pattern that assumes ASCII will do something surprising with NFC versus NFD Unicode. If you match names or paths, include a non-ASCII example.

The rest of the pipeline. Splitting on a regex and then parsing JSON of each chunk will fail when the JSON was already invalid. Fix the JSON - How to Fix Invalid JSON - instead of adding a more heroic pattern.

Security. Regex is a terrible HTML sanitizer. Do not “strip tags” with \<.*?\> and call the output safe.

Performance in a hot path. A tester with one string will not show you a 50 ms compile on every request. Measure in the app if the pattern runs on every event.

A tester will also not redact the paste for you. If you must use a real line, strip tokens first.

Limits, stated plainly

This is not a full language workbench with a step debugger, a timeout slider, and every flavor in a dropdown. It is enough to see matches before you commit. Very large fixtures can strain the tab; cut them down to the interesting region.

If the problem is “I need to rename symbols consistently,” start with case conventions, then use regex only for the leftover pattern. If the problem is “I need to parse HTML,” use a parser.

Test the near miss, then paste the pattern into code

When the must-match list hits, the must-not list stays quiet, and a near miss fails the way you want, copy the pattern into the runtime and run the same list there. Open Regex Testing for the discovery pass. Keep customer strings out of both places if you can; when you cannot, prefer the local tab to a public debugger, then delete the paste when you are done.