A URL slug rule
Input
lowercase + digits + underscore and dash, length 3 to 40, anchored
Result
^[a-z0-9_-]{3,40}$Accepts release-2026 and softkey_tools, rejects "My Post" because uppercase and spaces are outside the class.
Create a baseline pattern for controlled text fields and validate it with examples.
^[a-z0-9_-]{8,16}$Use this pattern as a starting point, then refine it for your exact validation rules.
Understand the format
A validation pattern is usually three decisions: which characters are allowed, how many of them, and whether the whole value must match. This builder makes each decision explicit.
Almost every field-validation regex has the same skeleton. A character class in square brackets lists the permitted characters, for example [a-z0-9_-]. A quantifier in braces states how many of them are allowed, for example {8,16}. Anchors, ^ at the start and $ at the end, force the pattern to describe the entire value rather than some fragment of it.
Anchors are the part people forget, and the omission is not cosmetic. Without them, the pattern [a-z]{3} matches inside "abc123!!", so a validator built on it accepts input it was meant to reject. If a field must match as a whole, anchor it.
Inside square brackets, most characters lose their special meaning, but a few keep it. A hyphen denotes a range unless it appears first or last, which is why a class that permits literal dashes is written as [a-z_-] rather than [a-z-_]. A caret means negation only in the first position. A closing bracket and a backslash always need escaping.
This builder handles that placement for you, but the rule is worth knowing when you edit the generated pattern by hand. Pattern bugs of this kind are silent: the expression still compiles, it simply matches a different set of characters than you intended.
Step by step
The pattern is assembled from your selections in the page. No input is sent anywhere, and no pattern is stored.
Worked examples
Input
lowercase + digits + underscore and dash, length 3 to 40, anchored
Result
^[a-z0-9_-]{3,40}$Accepts release-2026 and softkey_tools, rejects "My Post" because uppercase and spaces are outside the class.
Input
uppercase + digits, minimum and maximum both 8, anchored
Result
^[A-Z0-9]{8}$When the two lengths are equal the quantifier collapses to {8}, which reads more clearly in code review.
Reference
| Token | Meaning | Note |
|---|---|---|
| [a-z] | Any one lowercase ASCII letter | Accented letters are not included. |
| [0-9] | Any one digit | Equivalent to \d in most engines. |
| \s | Any whitespace character | Includes tabs and newlines, not only spaces. |
| {3,40} | Between 3 and 40 repetitions | Both bounds are inclusive. |
| {8} | Exactly 8 repetitions | Produced when the minimum equals the maximum. |
| ^ ... $ | Anchors at start and end of input | With the m flag these anchor each line instead. |
Practical Guide
Troubleshooting
FAQ
Usually an invisible character: a trailing space, a non-breaking space pasted from a web page, or a carriage return at the end of a line. Trim the input before validating.
Character classes, quantifiers, and anchors behave the same in JavaScript, Python, Java, Go, and PCRE. Named groups, lookbehind, and Unicode escapes differ, so verify anything beyond the basics in your target runtime.
Use a regex for shape, and code for meaning. A pattern can confirm a value looks like a reference code; only a lookup can confirm the code exists.
It wraps the pattern in ^ and $, which turns "contains a match" into "the entire value matches". For field validation you almost always want it on.
Yes. Add it inside the square brackets of the generated pattern, keeping a literal hyphen first or last so it is not read as a range.
Go deeper