Skip to content
tooljo Regex tools in: Dev tools
100% in your browser. Nothing you paste is uploaded — all processing runs locally. Read more →

30 regex one-liners I actually use weekly (with a tester link for each)

10 min reference #regex #javascript #patterns #cheatsheet

Most regex you’ll write is one-off. But there’s a small set of patterns that come up week after week — IDs, dates, log lines, URL parts. This is the curated list. Each entry has the pattern, a worked example, what it actually catches and misses, and a one-click link to load it into our tester.

Patterns are written for JavaScript / ECMAScript flavor. PCRE users: most work as-is; lookbehind and the v flag are JS-specific. See regex flavors for cross-language details.

Identifiers

1. UUID (canonical, any version)

^[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}$

Exact UUID format check. Use the case-insensitive i flag if you want to accept uppercase. Doesn’t validate the version bits — this is shape-only. To check that it’s a valid v4 specifically, use our validator.

2. UUID v7 specifically

^[0-9a-f]{8}-[0-9a-f]{4}-7[0-9a-f]{3}-[89ab][0-9a-f]{3}-[0-9a-f]{12}$

The 7 after the third group’s first byte enforces v7. The [89ab] after the fourth group enforces the RFC 4122 variant. Add the i flag for uppercase tolerance.

3. ULID

^[0-9A-HJKMNP-TV-Z]{26}$

ULIDs are 26 chars, Crockford base32 (drops I L O U).

4. ObjectId (MongoDB)

^[0-9a-f]{24}$

24 hex characters. Add i if your data might be uppercase.

Dates and times

5. ISO 8601 date

^\d{4}-\d{2}-\d{2}(T\d{2}:\d{2}(:\d{2}(\.\d+)?)?(Z|[+-]\d{2}:\d{2})?)?$

Matches 2025-01-01, 2025-01-01T00:00:00Z, 2025-01-01T00:00:00.123+09:00. Strict on the date portion; flexible on the optional time and timezone.

6. Unix timestamp (10 or 13 digits)

^\d{10,13}$

10 digits = seconds; 13 digits = milliseconds. Distinguish them by magnitude in code. To parse, see our epoch converter.

7. US date (M/D/YYYY)

^(0?[1-9]|1[0-2])\/(0?[1-9]|[12]\d|3[01])\/\d{4}$

Doesn’t validate impossible dates like Feb 31 — that takes a real parser.

8. Time HH:MM (24-hour)

^([01]\d|2[0-3]):[0-5]\d$

Matches 00:00 through 23:59. Add (:[0-5]\d)? for optional seconds.

URLs and email

9. URL (loose, captures the common cases)

^https?:\/\/[^\s]+$

The “casual” URL regex. Matches http://... and https://... through to whitespace. Does NOT validate IDN, percent-encoding, or RFC 3986 subtleties.

10. URL (strict — but not really)

You’ll find regexes claiming to validate every RFC 3986 URL. Don’t use them. Use a real parser:

try { new URL(input); } catch { /* invalid */ }

The “URL regex” everyone copies is wrong. See our breakdown of why (coming).

11. Email (the practical version)

^[^\s@]+@[^\s@]+\.[^\s@]+$

Three rules: something before @, something after @, has at least one . after @. Catches “obviously not an email” without trying to be RFC 5322 compliant.

If you need stricter, the only correct path is to send a confirmation email. Even RFC 5322 allows things like "Mary Sue"@domain.com.

12. Domain name

^([a-z0-9]([a-z0-9-]{0,61}[a-z0-9])?\.)+[a-z]{2,}$

Each label is 1–63 chars, no leading/trailing hyphen, ends with a TLD of at least 2 chars. Doesn’t handle internationalized domain names (xn— prefix); for that, normalize to ASCII first.

13. Slug (URL-safe identifier)

^[a-z0-9]+(?:-[a-z0-9]+)*$

Lowercase letters, digits, and single hyphens between segments. No leading/trailing/consecutive hyphens. The format used for blog post URLs.

Files and paths

14. Filename without path

([^/\\]+)$

Captures the basename — last segment after / or \. Works for both Unix and Windows paths.

15. File extension

\.([^.\/\\]+)$

The portion after the last ., ignoring path separators. Captures txt from report.final.txt.

16. Path with no extension

^.*[^./\\]$

Useful for filtering out anything with an extension. Inverse: \.[^.]+$.

Numbers

17. Integer (positive or negative)

^-?\d+$

18. Float / decimal

^-?\d+(\.\d+)?$

19. Number with thousands separators

^-?\d{1,3}(,\d{3})*(\.\d+)?$

Matches 1,234.56 and -1,000,000. US/UK format. Swap , and . for European format.

20. Hex color

^#?[0-9a-fA-F]{3}([0-9a-fA-F]{3})?([0-9a-fA-F]{2})?$

Matches #abc, #abcdef, #abcdef12 (with alpha). Optional leading #. See our color converter.

Common parsing tasks

\[([^\]]+)\]\(([^)]+)\)

Captures [text](url). Group 1 is the text, group 2 is the URL. Doesn’t handle nested brackets in the text — for that, use a real markdown parser.

22. HTTP request line

^(GET|POST|PUT|DELETE|PATCH|HEAD|OPTIONS) (\S+) HTTP\/(\d\.\d)$

Captures method, path, and HTTP version. Useful for log parsing.

23. IPv4 address

^((25[0-5]|2[0-4]\d|[01]?\d{1,2})\.){3}(25[0-5]|2[0-4]\d|[01]?\d{1,2})$

Strict — rejects 999.999.999.999. The [01]?\d{1,2} portion allows leading zeros (01.02.03.04); some systems consider those octal which can be a security issue.

24. IPv6 address (simplified)

^([0-9a-fA-F]{1,4}:){7}[0-9a-fA-F]{1,4}$

The full IPv6 regex with all :: compression rules is ~100 characters. For real validation use a parser; this matches the fully-expanded form.

25. MAC address

^([0-9a-fA-F]{2}[:-]){5}[0-9a-fA-F]{2}$

Six groups of 2 hex chars separated by : or -.

Versioning

26. Semantic version

^\d+\.\d+\.\d+(?:-[a-zA-Z0-9.-]+)?(?:\+[a-zA-Z0-9.-]+)?$

Matches 1.2.3, 1.2.3-alpha, 1.2.3-rc.1+build.123. The official semver regex from semver.org is more strict; this is the practical version.

27. Git short SHA

^[0-9a-f]{7,40}$

Git hashes are 40 hex chars; common abbreviations are 7–10. Add i if your data uses uppercase.

Whitespace and structure

28. Empty / whitespace-only line

^\s*$

Add the m flag for multiline matching across a document. Useful for stripping blank lines.

29. Leading whitespace (each line)

^[ \t]+

With the m flag and replace, this strips leading spaces/tabs. Doesn’t touch other whitespace.

30. Match anything between fenced markers

```([\s\S]*?)```

Lazy match between triple backticks. The [\s\S] trick matches any character including newlines (alternative to the s flag).

A few honourable mentions

Credit card numbers (loose)

^\d{13,19}$

After stripping spaces and dashes. Real validation needs the Luhn checksum, not regex.

Phone numbers

The international “phone number regex” is a famous black hole. Use Google’s libphonenumber. Regex won’t get you there.

Hashtags

#[\p{L}\p{N}_]+

With the u flag (unicode). Allows non-Latin letters and digits. Without the u flag, only ASCII.

Color in CSS source

#[0-9a-f]{3,8}\b|rgba?\(|hsla?\(|oklch\(

Matches the start of any CSS color literal. Useful for find-and-replace when migrating to OKLCH.

How to use this list

  1. Copy the pattern from above.
  2. Paste into our tester — change the test text to match your data.
  3. Look at the matches and capture groups.
  4. Iterate.

Most “the email/URL/IP regex doesn’t work” bug reports come from people who copied a pattern and didn’t actually look at what it matched. Always test against both happy-path and adversarial inputs.

Further reading

A note on validation

For most of these patterns, regex is the wrong tool for full validation. Email, URL, phone, IPv6 — each has corner cases that regex can’t reasonably express. Use regex to filter the obvious junk, then hand off to a real parser.

The patterns above are good for: filtering log lines, extracting fields from semi-structured text, quick UI input filtering, and “is this a UUID-shaped value or noise”. Don’t deploy them as the sole gate on production data.