Caveat: It checks the shape only. It accepts addresses without a dot in the domain (user@localhost) and rejects some that RFC 5322 allows (quoted local parts, non-ASCII addresses). No regex can tell whether a mailbox exists or receives mail.
Caveat: It does not accept IP addresses, localhost or internationalised host names, and it does not check the path. To really parse or validate a URL in JavaScript, use new URL(text) in a try/catch.
Caveat: Zone indexes (fe80::1%eth0) and CIDR prefixes are not accepted. It is long because it lists each place where :: may appear; that keeps it exact without backtracking risk.
Caveat: Second 60 is allowed for leap seconds. Like the date pattern, it does not check month lengths. RFC 3339 also permits a lowercase t and z and a space separator; this pattern does not.
00000000-0000-0000-0000-000000000000 (does not match)
123e4567e89b12d3a456426614174000 (does not match)
123e4567-e89b-12d3-c456-426614174000 (does not match)
123e4567-e89b-92d3-a456-42661417400 (does not match)
Caveat: The nil UUID (all zeros) and the max UUID (all f) are valid but rejected here because their version digit is 0 or f. Drop the version and variant checks to accept any 8-4-4-4-12 hex string.
The international format phone systems use: a plus sign, a country code and up to 15 digits in total, no spaces.
/^\+[1-9]\d{1,14}$/
Matches
+14155552671 (matches)
+442071838750 (matches)
+819012345678 (matches)
Does not match
14155552671 (does not match)
+0123456789 (does not match)
+1 415 555 2671 (does not match)
+1234567890123456 (does not match)
Caveat: It checks length and characters, not whether the country code or number exists. Normalise user input (strip spaces, dashes and brackets) before testing.
Caveat: It follows the general format but not every rule about which letters may appear in each position, so a few impossible postcodes pass. Use an address lookup if you need real postcodes.
An integer or decimal with an optional sign and exponent: 42, -3.14, .5, 6.02e23.
/^[+-]?(?:\d+(?:\.\d*)?|\.\d+)(?:e[+-]?\d+)?$/i
Matches
42 (matches)
-3.14 (matches)
.5 (matches)
6.02e23 (matches)
+1E-9 (matches)
10. (matches)
Does not match
(empty) (does not match)
. (does not match)
1,000 (does not match)
1.2.3 (does not match)
e5 (does not match)
--1 (does not match)
Caveat: No thousands separators and only a dot as the decimal mark. It is written so that each digit can only be matched one way (\d+\.?\d* would backtrack quadratically on long digit runs).
Inline Markdown links [text](url), capturing the link text in group 1 and the address in group 2.
/\[([^\]]+)\]\(([^)\s]+)\)/g
In “See [the docs](https://example.com/docs) and [home](/).” it finds
[the docs](https://example.com/docs) (matches)
[home](/) (matches)
Caveat: Nested brackets in the text, titles after the URL and URLs containing ) are not handled; use a Markdown parser for anything beyond quick edits.
Caveat: Composition rules like these are no longer recommended on their own: NIST guidance favours length and checking against breached-password lists. Use this as an example of lookaheads.
Every validation pattern here is anchored with ^ and $, so it checks a whole value such as a form field. To find the same thing inside longer text, remove the anchors and add the g flag, or use \b where it makes sense. Open in tester loads the pattern with all its examples, one per line, with the m flag added so the anchors work line by line.
Regexes are best at format. A pattern can confirm that a date is written YYYY-MM-DD, not that the day exists; that an address has the shape of an email, not that someone reads it. Pair them with real parsing (new URL(), Date, a postcode lookup) when correctness matters, and keep length limits on untrusted input.
Each card’s Try your own value box tests input against the pattern as you type, entirely in your browser.
Questions
Do these patterns work outside JavaScript?
Most use syntax shared by every major flavour. Named groups, \p{…} and the v flag are the exceptions; the tester’s Code tab converts a pattern for Python, PHP, Go and Java and lists what differs.
Why not the “complete” RFC 5322 email regex?
It is thousands of characters long, accepts addresses no mail provider hands out, and still cannot tell whether a mailbox exists. The browser’s own rule is a better balance; send a confirmation email to be sure.
Can I use them in commercial projects?
Yes. Short patterns like these are standard building blocks; the semantic version pattern is the one published on semver.org.