Regex Tester: Write and Debug Regular Expressions Interactively

Writing regex in your head and testing it directly in production code is a great way to cause an incident. The CalcHub Regex Tester lets you write a pattern, paste in test data, and see exactly what matches (and what doesn't) before you put it anywhere near real code.

How It Works

The tool has three main areas:

1. Pattern field — your regex, without the surrounding slashes
2. Flags — g (global), i (case-insensitive), m (multiline), s (dotAll), u (unicode)
3. Test string — the text you want to match against

As you type, matches are highlighted in the test string in real time. Below the editor, you'll see a detailed breakdown: full matches, any capture groups, match index positions, and the total match count.

Quick Regex Reference

Pattern	Matches
.	Any single character (except newline)
\d	A digit (0–9)
\w	A word character (letters, digits, underscore)
\s	Whitespace (space, tab, newline)
^	Start of string (or line with m flag)
$	End of string (or line with m flag)
*	Zero or more of the preceding element
+	One or more of the preceding element
?	Zero or one (makes quantifiers lazy when appended)
{n,m}	Between n and m repetitions
[abc]	Any of a, b, or c
[^abc]	Any character except a, b, or c
(...)	Capture group
(?:...)	Non-capturing group
(?=...)	Positive lookahead
(?!...)	Negative lookahead

Common Patterns Worth Having

These are patterns you'll reach for repeatedly:

# Email address (simplified but practical)
^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$

# URL
https?:\/\/(www\.)?[-a-zA-Z0-9@:%._+~#=]{1,256}\.[a-zA-Z0-9()]{1,6}\b([-a-zA-Z0-9()@:%_+.~#?&/=]*)

# IPv4 address
\b(?:(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.){3}(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\b

# ISO 8601 date
\d{4}-(?:0[1-9]|1[0-2])-(?:0[1-9]|[12]\d|3[01])

# Hex color code
#([A-Fa-f0-9]{6}|[A-Fa-f0-9]{3})\b

# Semantic version
\bv?(?:0|[1-9]\d)\.(?:0|[1-9]\d)\.(?:0|[1-9]\d)(?:-[0-9A-Za-z-]+(?:\.[0-9A-Za-z-]+))?(?:\+[0-9A-Za-z-]+(?:\.[0-9A-Za-z-]+)*)?\b

Paste these into the tester, throw your test data at them, and tweak as needed.

Practical Scenarios

Input validation. Testing whether a phone number, postal code, or username field matches the expected format before writing the validation logic into your app. Log parsing. Server logs are a goldmine of structured data if you can extract it. Writing a regex to pull timestamps, status codes, request paths, and IP addresses from Apache or Nginx logs is a lot more comfortable when you can see the matches live. Search and replace. Before running a global find-and-replace across a codebase with sed or your editor's regex replace, test the pattern here to make sure it's not catching unintended things. Sanitization patterns. Testing that your "strip HTML tags" or "remove special characters" patterns are actually catching everything they should and not eating legitimate input. Data extraction from text. Pulling structured information from unstructured sources — extracting all URLs from a blob of text, finding all function names in source code, extracting amounts from invoice text.

Tips for Writing Better Regex

Be as specific as possible. Overly broad patterns like .* match things you didn't intend. Use character classes ([a-z0-9]) and quantifiers ({2,4}) to constrain your match. Use non-capturing groups for grouping without overhead. If you're grouping just to apply a quantifier and don't need the captured value, use (?:...) instead of (...). It's faster and keeps your capture group numbering clean. Anchor when validating. For input validation (you want the entire string to match, not just part of it), always anchor with ^ and $. Without anchors, \d+ will match abc123def — it finds the digits in the middle. Watch out for catastrophic backtracking. Patterns like (a+)+b applied to a long string of as that doesn't end in b can cause exponential slowdowns. Test with worst-case inputs, not just happy-path ones.

---

What's the difference between . and .??

The . quantifier is greedy — it matches as much as possible. .? is lazy — it matches as little as possible. When extracting content between tags, <.> will match the entire string bold and italic, while <.?> will match , , , and separately. The lazy version is almost always what you want for tag-like patterns.

Why does my regex work in the tester but not in my code?

A few common culprits: the g flag — without it, String.match() in JavaScript only returns the first match. Also check whether you're using the regex literal syntax (/pattern/flags) or new RegExp("pattern", "flags") — in the latter, backslashes need to be doubled (\\d instead of \d). Test with the same flags you're using in code.

Should I use regex or a proper parser for HTML/XML?

Use a proper parser. Regex can handle simple, known patterns in HTML, but for anything general-purpose, it will break. HTML is not a regular language, and attempts to parse it with regex lead to unmaintainable patterns that break on edge cases. Use DOMParser in the browser, cheerio or parse5 in Node.js.

---

Related Tools on CalcHub

• JSON Formatter — use regex to find patterns in large JSON blobs before formatting
• Color Picker — after extracting hex codes with regex, convert them
• Base64 Encoder — encode the results of text extraction for transport