Regex Tester
Real-time regex validation, debugging, and a built-in library of common patterns.
Regex Pattern
Enter pattern between / /, toggle flags as needed
Match Results
Presets are quick starting points for common format checks. For production, business-level validation (value ranges, real-world validity) still needs to be confirmed in code.
Syntax Reference
Common regex flags and metacharacter quick reference
gGlobalFind all matches, not just the first one.
iCase-InsensitiveIgnore letter casing — A and a match each other.
mMultilineMakes ^ and $ match the start/end of each line.
sdotAllMakes . match all characters, including newlines.
^ / $Anchors^ matches line start, $ matches line end (per-line in m mode).
.Any CharMatches any character except newline (all in s mode).
* + ?Quantifiers* zero or more, + one or more, ? zero or one.
[abc]Char ClassMatches any char in brackets; [^abc] negates; [a-z] range.
\d \w \sShorthands\d digit, \w word char, \s whitespace.
What is the Regex Tester?
Regular expressions (Regex) are sequences of characters that define search patterns, used in virtually every programming language for text validation, searching, and extraction. From validating email formats to parsing massive log files, Regex is one of the most powerful tools in a developer's arsenal.
This tester provides a real-time feedback environment so you can quickly verify your regex patterns before writing them into application code. It supports flags including global (g), multiline (m), and case-insensitive (i), with clear match highlighting. It also includes a built-in library of common patterns covering high-frequency scenarios like emails, URLs, IPv4 addresses, and phone numbers.
How to use this tool
Write your regex pattern in the input field at the top of the page (no need to wrap it in delimiter slashes) and select the flags you need. Type or paste your test string in the left text area. Watch the right panel — the system will instantly annotate all matches and display the total count.
If you're new to regex or need quick solutions for common tasks, expand the "Common Patterns" sidebar on the left and click any preset to load it instantly. All matching and computation happens locally in your browser — your data is 100% private and secure.
Typical DevOps Use Cases
(?P<ts>\d{4}-\d{2}-\d{2})Extracting timestamps, log levels, and request paths from Nginx or application logs is one of the most common DevOps regex tasks. Named capture groups ((?P<ts>\d-\d-\d)) are far more maintainable than indexed groups. Watch engine dialects: grep defaults to BRE which does not support \d or non-capturing groups — use -E for ERE or -P for PCRE. awk uses ERE by default. Always confirm the target engine's dialect before porting patterns to avoid silent mismatches.
^v?\d+\.\d+\.\d+$CI/CD pipelines frequently need to validate Git tags against SemVer. \d+\.\d+\.\d+(-[\w.]+)? covers both 1.2.3 and 1.2.3-rc.1, but you must add anchors — ^v?\d+\.\d+\.\d+$ — to prevent "1.2.3-dirty" from being treated as a release version. GitHub Actions on.push.tags only supports simplified globs (v[0-9].*); for strict shell validation, use bash's inline [[ "$TAG" =~ regex ]] to avoid spawning a grep subprocess.
\b(\d{1,3}\.){3}\d{1,3}\bgrep -Eo can bulk-extract IP addresses from logs, but pure regex cannot validate the numeric range — 999.999.999.999 also matches. Filter private subnets with a second grep -v pass. For authoritative validation in application code, use a purpose-built library (Python ipaddress, Go net.ParseIP) rather than pure regex. The right layered strategy — regex for extraction, library for validation — is far more reliable in production.
(?<=password=)[^&]+Redacting tokens and passwords from logs before they reach storage is a core compliance requirement. In bash, sed with back-references can replace Authorization header values in-place. In Python, lookbehinds like (?<=password=) replace only the value without touching the key. Remember: regex masking is best-effort. Private keys, full PAN numbers, and similar data must be structurally filtered before entering the logging pipeline — the log store may already have persisted a copy by the time you scrub it.
^(main|feature/|release/)GitLab CI and GitHub Actions trigger rules support simplified globs, but complex strategies (multi-condition triggers, hotfix branch detection) still require regex in shell scripts. Common patterns: ^(main|master|develop)$ for exact trunk matching; ^feature/ for all feature branches; ^release/\d+\.\d+ to trigger only release pipelines. bash's inline [[ "$BRANCH" =~ pattern ]] is faster than spawning a grep subprocess and is preferred in high-frequency pipeline scripts.
^([\w.]+)\s*=\s*(.+)$For .env or INI-format parsing, ^([\w.]+)\s*=\s*(.+)$ captures the key in group 1 and value in group 2, handling optional whitespace around the equals sign. Filter comment and blank lines first with ^\s*(#|$). Never source .env files directly in production — a value containing shell metacharacters or command substitution will execute arbitrary code. Use explicit grep or awk to extract individual keys, or a dedicated dotenv library for safe parsing.
Common Mistake Patterns
Greedy quantifiers (*, +) match as much as possible by default, causing over-matching when parsing HTML or structured text. The classic trap: <.*> on "<p>text</p>" returns the entire string rather than the first tag. The fix is a lazy quantifier (<.*?>) or a negated character class (<[^>]+>). The negated class is generally faster — it tells the engine that > cannot appear inside the match, eliminating all backtracking. In large documents, the speed difference can be orders of magnitude.
Catastrophic backtracking is the root cause of ReDoS (Regular Expression Denial of Service) attacks. It is triggered by nested quantifiers like (a+)+ or overlapping alternation branches like (ab|a)+, forcing the engine to explore exponentially many paths before failing. Mitigate by being explicit with quantifiers ({1,50} over +), avoiding adjacent quantifiers with overlapping character sets, and adding execution timeouts around regex calls in production code. Integrate static analysis tools like safe-regex in CI to catch dangerous patterns before they ship.
Forgetting the multiline flag (m) causes ^ and $ to anchor to the entire string instead of individual lines — a frequent bug when processing log files line by line. A separate common mistake is escape confusion: in JS/Python string literals, \d is interpreted as a literal d (the backslash is consumed), so you need \\d or a raw string (Python r'\d'). In Unicode contexts, \w only covers ASCII word characters by default — to match CJK or other non-ASCII letters, enable the u flag (JavaScript) or use Unicode property escapes (\p) with an engine that supports them.