validation
Domain Name Regex Pattern
Validates a domain name per DNS rules: total length ≤ 253 chars, each label 1-63 chars, no leading or trailing dashes, TLD is letters only and at least 2 characters. Doesn't check that the domain actually resolves.
/^(?=.{1,253}$)([a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?\.)+[a-zA-Z]{2,}$/ What each part matches
(?=.{1,253}$) — lookahead: total length up to 253 chars[a-zA-Z0-9] — label starts with alphanumeric(?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])? — optional middle + must end in alphanumeric\.)+ — at least one dot-terminated label[a-zA-Z]{2,}$ — TLD: 2+ letters✓ These match
- example.com
- sub.domain.co.uk
- my-site.io
- a.b
✗ These don't
- -example.com
- example-.com
- example
- example..com
Use in your code
JavaScript
const re = /^(?=.{1,253}$)([a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?\.)+[a-zA-Z]{2,}$/;
re.test(input); // → true or false Python
import re
re.fullmatch(r"^(?=.{1,253}$)([a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?\.)+[a-zA-Z]{2,}$", input) PHP (PCRE)
preg_match('/^(?=.{1,253}$)([a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?\.)+[a-zA-Z]{2,}$/', $input); Go
re := regexp.MustCompile(`^(?=.{1,253}$)([a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?\.)+[a-zA-Z]{2,}$`)
re.MatchString(input) FAQ
Does this domain name regex work in JavaScript?
Yes. Every pattern in the Utilko regex library is tested to work in JavaScript RegExp, PCRE (PHP, Nginx), and Python `re`. Where flavor matters (lookbehind, named groups), the pattern page flags it.
How do I use this pattern?
Copy the pattern from the code block above. In JavaScript:
new RegExp('^(?=.{1,253}$)([a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?\.)+[a-zA-Z]{2,}$') or literal /^(?=.{1,253}$)([a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?\.)+[a-zA-Z]{2,}$/. Or click "Try in regex tester" to open it pre-loaded in Utilko's browser-based regex tester.Should I use this for security-critical validation?
Client-side regex is fine for UX (immediate feedback on a form). For anything security-critical — payments, auth, data integrity — always re-validate server-side using the same pattern PLUS domain-specific checks (Luhn checksum for cards, actual email delivery test, DNS resolution for domains).