Use a pattern as a starting point, then test it in your target engine. Matching a format does not prove that an address, date or account is valid.
Runs locally in your browser| Use case | Regular expression | Notes |
|---|---|---|
| Email address | ^[^\s@]+@[^\s@]+\.[^\s@]+$ |
Practical syntax check; delivery requires verification. |
| HTTP or HTTPS URL | ^https?:\/\/[^\s]+$ |
Checks the scheme and rejects whitespace; use a URL parser for full validation. |
| IPv4 address | ^(?:(?:25[0-5]|2[0-4]\d|1?\d?\d)\.){3}(?:25[0-5]|2[0-4]\d|1?\d?\d)$ |
Accepts octets from 0 through 255. |
| UUID versions 1–5 | ^[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-5][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}$ |
Checks the standard hyphenated form and RFC variant bits. |
| ISO-style date | ^\d{4}-(0[1-9]|1[0-2])-(0[1-9]|[12]\d|3[01])$ |
Checks YYYY-MM-DD shape, not month-specific day limits. |
| 24-hour time | ^(?:[01]\d|2[0-3]):[0-5]\d$ |
Accepts values from 00:00 through 23:59. |
| Hex color | ^#(?:[0-9a-fA-F]{3}|[0-9a-fA-F]{6}|[0-9a-fA-F]{8})$ |
Supports RGB, RRGGBB, and RRGGBBAA notation. |
| Semantic version | ^(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-]+)*)?$ |
Matches core versions plus optional prerelease and build metadata. |
| Signed integer | ^-?\d+$ |
Allows an optional minus sign. |
| Decimal number | ^-?(?:\d+|\d*\.\d+)$ |
Accepts integers and decimal fractions, including values such as .5. |
| URL slug | ^[a-z0-9]+(?:-[a-z0-9]+)*$ |
Lowercase ASCII words separated by single hyphens. |
| HTML-like tag | <\/?[A-Za-z][^>]*> |
Useful for simple extraction only; parse HTML with an HTML parser. |
| Leading or trailing whitespace | ^\s+|\s+$ |
Use the global flag when removing whitespace from both ends. |
| Blank line | ^\s*$ |
Use multiline mode to evaluate each line separately. |
| Repeated adjacent word | \b([A-Za-z]+)\s+\1\b |
Use case-insensitive mode if capitalization should be ignored. |
JavaScript, PCRE, Python, Java, .NET, Go, and Ruby do not implement exactly the same regex features. Check the target engine before relying on lookbehind, named groups, Unicode properties, possessive quantifiers, or inline modifiers.
For security-sensitive validation, normalize the input first, apply explicit length limits, and use a dedicated parser whenever the data format has one.
Fifteen ready-made patterns for the values a form, a log line or a config file usually has to check: e-mail address, HTTP or HTTPS URL, IPv4 address, UUID versions 1-5, ISO-style date, 24-hour time, hex colour, semantic version, signed integer, decimal number, URL slug, HTML-like tag, leading or trailing whitespace, blank line and repeated adjacent word.
The table is the whole page: there is no box to type into and nothing to run. Each row says what its pattern checks and what it leaves alone, because matching a format is not the same as validating real data. The date row accepts 2024-02-31 and the e-mail row cannot know whether an address receives mail, so treat a pattern as a starting point and test it in the engine that will run it.
The IPv4 row accepts 0.0.0.0 and 255.255.255.255 and rejects 256.1.1.1, 1.2.3 and 1.2.3.4.5. The UUID row wants the hyphenated form with a version digit of 1 to 5 and an RFC variant nibble of 8, 9, a or b, so version 6 and 7 identifiers do not match. The semantic-version row accepts 1.0.0, 1.0.0-alpha.1 and 1.0.0+build.1 while v1.0.0 and 01.0.0 fail.
Several rows are deliberately loose. 2024-02-31 passes the date row because month lengths are unknown to the pattern, and 2024-13-01 fails. The time row expects two digits, so 09:30 matches and 9:30 does not. The integer row rejects +5, the decimal row accepts .5 and rejects 5., and the slug row keeps hyphens single and letters lower-case.
The filter reads the whole row, not only its title: 'octet' finds the IPv4 row through its note, '^https' finds the URL row through the pattern itself, and 'blank' finds the blank-line row. The counter reads out of 15 and never guesses, Escape clears the box while it has focus, and the Clear button does the same for a touch screen.
The row button copies the regular expression only, anchors included and no surrounding quotes, so the result can go straight into source code, a test file or a validation rule. The use case and the note stay on the page: they are context, not part of the pattern.
Three rows only do their job with the right flags: the outer-whitespace row needs the global flag to strip both ends, the blank-line row needs multiline mode so ^ and $ are evaluated per line, and the repeated-word row needs the case-insensitive flag to read 'The the' as a repeat.
The larger limit is portability. Lookbehind, named groups, Unicode property escapes and possessive quantifiers are not implemented in the same way by JavaScript, PCRE, Python, Java, .NET, Go and Ruby, and a pattern lifted from this page inherits the assumptions of the engine it was written for. Check the target engine's documentation and keep the expression in a test that runs on the strings your service really sees.