How to Test Regular Expressions Online - Free Regex Tester
Regular expressions are powerful and famously easy to get wrong. A pattern that looks correct can silently miss matches, grab too much, or freeze your program on a tricky input. The fastest way to build a working regex is to test it live against real sample text and watch what it matches. This guide walks through the core syntax, the most useful flags, common patterns for email, phone, and URL, and the mistakes that trip up almost everyone. Try each example in a free in-browser regex tester as you read.
- A regex is a text-matching pattern built from literals, character classes, quantifiers, anchors, and groups.
- Live testing with highlighting is the fastest way to debug a pattern, since regex is concise but error-prone.
- Greedy quantifiers match as much as possible; add a question mark to make them lazy.
- Watch for catastrophic backtracking, a real denial-of-service risk that has caused major outages, including a 2019 Cloudflare incident.
What Is a Regular Expression?
A regular expression, or regex, is a compact pattern that describes a set of strings for searching, matching, and replacing text. The concept dates to Stephen Kleene's 1951 work on regular languages, and it is now built into nearly every programming language (Kleene, 1951). It is the standard tool for text processing.
Think of a regex as a search query on steroids. Instead of finding one exact string, it finds every string that fits a shape: "any sequence of digits," "an email-like token," "a word at the start of a line." That expressiveness is what makes regex indispensable for validation, extraction, and find-and-replace.
Where you will use regex
Regex shows up everywhere text is processed. Developers use it to validate form input, extract data from logs, rewrite URLs, search codebases, and clean up messy data files. Even non-programmers meet it in advanced find-and-replace inside editors. Learning it once pays off across countless tools.
What Is the Basic Regex Syntax?
Regex syntax combines literal characters with metacharacters that carry special meaning. The building blocks are character classes, quantifiers, anchors, and groups. These are shared across virtually every regex engine, from JavaScript to Python to PCRE, which is why the fundamentals transfer almost everywhere you work.
Literals match themselves: the pattern cat matches the text "cat". The power comes from metacharacters. Below are the essentials you will reach for constantly. Test each one in a regex tester to see exactly what it captures.
| Element | Syntax | Matches |
|---|---|---|
| Character class | [a-z] | Any single lowercase letter |
| Digit shorthand | \d | Any digit 0-9 |
| Any character | . | Any single character except newline |
| Zero or more | * | Preceding item, 0 or more times |
| One or more | + | Preceding item, 1 or more times |
| Optional | ? | Preceding item, 0 or 1 time |
| Exact count | {3} | Preceding item, exactly 3 times |
| Start anchor | ^ | Start of string or line |
| End anchor | $ | End of string or line |
| Group | (...) | Groups a sub-pattern, captures it |
Putting pieces together
Combine these and patterns get expressive fast. The pattern ^\d{3}-\d{4}$ matches a string that is exactly three digits, a hyphen, then four digits, like a short phone code. Reading a regex left to right while testing it is the quickest way to build intuition.
What Do Regex Flags Do?
Flags modify how the whole pattern behaves. The three you will use most are global, case-insensitive, and multiline. Global finds every match instead of just the first. Case-insensitive ignores letter case. Multiline changes how the start and end anchors treat line breaks within the text.
A quick tip: flag behavior is one of the small areas where regex flavors diverge. The dot-all flag, for instance, is spelled differently or behaves differently in some older engines. When a pattern works in one language but not another, flags are often the culprit.
Common Patterns: Email, Phone, and URL
Most real-world regex work reuses a handful of patterns. Email, phone number, and URL validation are the classics. Fully strict versions are surprisingly hard, the official email standard, RFC 5322, allows patterns so complex that a complete regex runs hundreds of characters, so practical patterns favor "good enough" over perfect.
Here are pragmatic starting points. Each one trades total correctness for readability and real-world usefulness. Always test them against your actual data, including the awkward edge cases, in a live tester before shipping.
| Goal | Practical pattern |
|---|---|
| Email (basic) | ^[^@\s]+@[^@\s]+\.[^@\s]+$ |
| US phone | ^\(?\d{3}\)?[-.\s]?\d{3}[-.\s]?\d{4}$ |
| URL (http/https) | ^https?:\/\/[^\s]+$ |
| US ZIP code | ^\d{5}(-\d{4})?$ |
The honest rule on email regex: use a simple pattern to catch obvious typos, then verify by sending an email. A regex tells you a string looks like an address; only a delivered message proves it works. Over-engineering the pattern wastes effort and often rejects valid addresses.
How Do Capture Groups Work?
Parentheses create a capture group, which stores the matched substring for reuse. Groups let you extract specific parts of a match rather than the whole thing. For example, (\d{4})-(\d{2})-(\d{2}) against a date captures the year, month, and day separately into numbered groups one, two, and three.
Capture groups power extraction and replacement. In a find-and-replace, you can reference a captured group in the replacement string to rearrange text. Reformatting "2026-06-17" into "17/06/2026" is a single regex replace once you have captured the three parts.
Named groups and non-capturing groups
Two refinements help on bigger patterns. Named groups let you label captures so you reference them by name instead of number, which keeps complex patterns readable. Non-capturing groups, written with (?:...), group a sub-pattern without storing it, which is useful when you only need the grouping for a quantifier.
What Are the Most Common Regex Mistakes?
The two costliest mistakes are forgetting to escape special characters and writing patterns that backtrack catastrophically. A 2019 Cloudflare outage that took much of the web offline for nearly 30 minutes was traced to a single regex with runaway backtracking (Cloudflare, 2019).
Escaping trips up everyone. The dot, plus, parentheses, and question mark all have special meaning. To match a literal dot, you escape it with a backslash. Inside a character class, many of these become literal automatically, which is a common source of confusion when a pattern behaves differently than expected.
Greedy vs lazy matching
Quantifiers are greedy by default, meaning they match as much as possible. Against the text <a><b>, the pattern <.+> matches the entire string, not just <a>. Add a question mark to make it lazy, <.+?>, and it matches the smallest possible piece. This single character flips behavior, and missing it causes endless confusion.
Beware catastrophic backtracking. Nested quantifiers like (a+)+ can force the engine to try exponentially many combinations on certain inputs, freezing your application. This is a genuine denial-of-service risk. Always test patterns against long, adversarial inputs before deploying them in production.
How Do You Test Regex Online with Live Highlighting?
The fastest workflow is to write the pattern and sample text side by side and watch matches highlight as you type. A browser-based tester compiles the regex locally and renders matches instantly. With FusionPDF, your data stays in your browser; nothing is sent to a server, so even sensitive sample text stays private.
Go to fusionpdf.pro/regex-tester. No account, no sign-up, no installation.
Type your regular expression into the pattern field. It compiles in your browser as you type, so there is no round-trip delay.
Drop in real sample data. Matches highlight instantly, and you can see exactly which characters each part of the pattern captures.
Switch global, case-insensitive, and multiline on or off, then adjust the pattern until the highlighting matches your intent.
Testing tip: always include edge cases in your sample text, empty values, very long lines, unusual punctuation, and near-misses that should not match. A pattern that passes only your happy-path examples will fail in production. Live highlighting makes those failures obvious immediately.
Once your pattern works, you can pair it with related tools. Use the text diff tool to compare before-and-after output of a replace, or the slug generator for the common task of turning titles into URL-safe strings.
Frequently Asked Questions
Is regex the same in JavaScript, Python, and PCRE?
Mostly, but not entirely. The core syntax, character classes, quantifiers, anchors, and groups, is shared across flavors. Differences appear in lookbehind support, named-group syntax, Unicode handling, and some escape sequences. A pattern that works in JavaScript may need small adjustments in Python or PCRE, so always test in the target environment before relying on it.
What is the difference between greedy and lazy matching?
Greedy quantifiers match as much as possible, then backtrack if needed. Lazy quantifiers, written by adding a question mark like *? or +?, match as little as possible. For example, against <a><b>, the greedy <.+> matches the whole string, while the lazy <.+?> matches just <a>.
How do I match a literal dot in regex?
Escape it with a backslash. An unescaped dot matches any single character, so to match an actual period you write a backslash followed by a dot. Inside a character class, the dot is already literal and needs no escaping. The same escaping rule applies to other special characters, such as parentheses, the plus sign, and the question mark.
What is a good regex to validate an email?
For practical use, a simple pattern that requires text, an at sign, a domain, a dot, and a top-level domain is enough. Fully RFC 5322-compliant email regex is enormously complex and rarely worth it. Most teams use a lightweight pattern for format checking, then confirm deliverability by sending a verification email to the address.
What is catastrophic backtracking and how do I avoid it?
Catastrophic backtracking happens when nested or ambiguous quantifiers force the engine to try exponentially many combinations on certain inputs, freezing your program. It is a real denial-of-service risk that caused a major Cloudflare outage in 2019. Avoid it by removing nested quantifiers like (a+)+, anchoring patterns, and testing against long edge-case inputs in a regex tester.
Test Your Regex Now
Free, instant, private. Live match highlighting, flags, and capture groups. Your data stays in your browser, nothing is sent to a server.
Open Regex Tester →