Regex Examples and Pattern Cheatsheet
Regular expressions are most useful when the pattern is narrow, tested and attached to a clear goal. This page collects practical JavaScript regex examples for everyday developer work: validation, extraction, cleanup and log parsing. Each example includes a short note about where the pattern works well and where it should be reviewed before production use.
How to Use These Examples
Copy a pattern into the Formalint Regex Matcher and Validator, paste representative test text, and verify both matching and non-matching cases. A useful regex test set should include normal values, empty values, malformed input, edge cases and values that look valid but should be rejected by your business rules.
Email Format Check
This is a practical form-level check, not a complete email specification parser. Use it to catch obvious mistakes, then confirm ownership with an email verification flow.
^[^\s@]+@[^\s@]+\.[^\s@]+$URL With HTTP or HTTPS
This pattern is useful for simple input validation where users must provide a web URL with an explicit protocol. For advanced URL handling, use the platform URL parser after the regex check.
^https?:\/\/[^\s/$.?#].[^\s]*$UUID v4
Use this when you need to validate UUID v4 strings in logs, test data or API parameters. The version and variant sections are constrained instead of accepting any UUID-looking value.
^[0-9a-f]{8}-[0-9a-f]{4}-4[0-9a-f]{3}-[89ab][0-9a-f]{3}-[0-9a-f]{12}$Slug
A slug pattern is useful for route segments, article URLs and simple identifiers. This version allows lowercase letters, numbers and single hyphens between words.
^[a-z0-9]+(?:-[a-z0-9]+)*$Hex Color
This pattern accepts common 3-digit and 6-digit CSS hex colors. It is a good fit for simple color inputs, design token checks and data cleanup scripts.
^#(?:[0-9a-fA-F]{3}){1,2}$ISO Date
This checks the shape of an ISO-style date. It does not verify calendar validity, so a second date parser should still reject impossible dates such as February 31.
^\d{4}-\d{2}-\d{2}$Log Level Extractor
Use this to extract common log levels from structured or semi-structured application logs. Capture groups make it easier to inspect the level and message separately.
^(INFO|WARN|ERROR|DEBUG)\s+(.+)$Query Parameter Pair
This pattern can help inspect query strings during debugging. It extracts one key-value pair at a time and keeps the separator out of the captured key and value.
(?:^|&)([^=&]+)=([^&]*)Common Regex Mistakes
Do not use a regex where a parser is safer. JSON, XML, URLs, dates and HTML all have edge cases that a dedicated parser handles better. Regex is best for a small, well-defined text shape. Watch for greedy quantifiers, missing anchors, unescaped dots, broad character classes and patterns that become slow on long input.
Test Checklist
Before shipping a regex, test valid examples, invalid examples, empty input, long input, Unicode input when relevant and input with leading or trailing whitespace. If the pattern protects a security boundary, treat it as one layer of validation rather than the only control.
Frequently Asked Questions
Are these regex examples safe for every production form?
No. They are practical starting points for common validation and parsing tasks. Production rules should be tested against your own data and adjusted for business requirements.
Which regex engine are these examples written for?
The examples are written for JavaScript regular expressions, matching the Formalint regex matcher and modern browser or Node.js behavior.
Should regex validate email addresses perfectly?
Most applications should use a practical email format check and then confirm deliverability through a verification email rather than trying to encode the entire email specification in one pattern.