Check whether your own slugs are valid

What a slug is, and what this pattern checks

A slug is the human-readable segment of a URL path that identifies one piece of content — the my-great-post in example.com/blog/my-great-post. Convention, not any standard, dictates its shape: lowercase, alphanumeric segments joined by single hyphens, with no leading or trailing hyphen and no doubled hyphen. This pattern validates that shape; it does not generate a slug from a title, which is a separate, harder problem covered further down.

Token by token

The group is non-capturing ((?:…), not (…)) because nothing here needs to read back which specific segment matched — it exists purely to give * something to repeat: “hyphen, then more characters”, as a unit, zero or more times. That single design choice is what makes the whole shape work: a hyphen can only ever appear immediately followed by at least one alphanumeric character, which is exactly what rules out a leading hyphen, a trailing one, and a doubled one, all in one small pattern rather than three separate checks.

What it matches

• hello-world — the ordinary case.
• abc123-def-456 — digits mixed into any segment.
• a — a single character is a valid slug; there is no minimum length beyond “at least one character”.

What it deliberately does not match, and why

Validating a slug is not the same as generating one

This pattern answers “is this string already slug-shaped”. Getting from an arbitrary title — My Great Post!, or Café Résumé, or a title written entirely in a non-Latin script — to a slug that passes this pattern is a different job, and a considerably harder one once non-ASCII text is involved. The mechanical part is straightforward: lowercase the string, strip characters outside the allowed set, and collapse runs of whitespace or removed characters into single hyphens. The judgement call is what happens to a character like é or ü or a Cyrillic or CJK character, since none of them fit [a-z0-9]. Two defensible strategies exist, and they produce very different slugs from the same title:

• Transliterate: convert é to e, ü to u, and so on, using a mapping table or a library, so Café becomes cafe. This keeps the slug ASCII and this pattern happy, at the cost of losing the distinction between accented and unaccented forms.
• Keep it Unicode: many modern platforms (including most blogging software) allow slugs containing the original non-Latin letters, relying on the browser and server to handle Unicode paths and percent-encoding correctly, rather than forcing everything through an ASCII transliteration. A pattern permitting this needs a Unicode property escape such as \p{L} in place of a-z, which requires the u flag and is governed by UTS #18’s rules for how a regex engine should classify Unicode letters — a materially different pattern from the ASCII-only one on this page, and one that then has to define its own rules for what “lowercase” means across scripts that do not have letter case at all (most CJK scripts, for instance).

This page’s pattern deliberately takes the first, ASCII-only stance, because it is the more common convention on the open web and the simpler one to reason about; if your platform has chosen the second, you need a different pattern than the one above, not a variation of it.

Flavour: this is JavaScript’s regex

This pattern targets JavaScript’s built-in RegExp, per ECMA-262. It uses only literals, a character class, +, * and a non-capturing group — every one of those is identical in PCRE and Python’s re, so this exact text ports unchanged. The Unicode variant discussed above, using \p{L}, needs the u flag in JavaScript specifically; PCRE spells the equivalent property class similarly but with its own flag conventions. See the cookbook’s flavour-honesty section for the rest of the differences.

Worked examples

function slugify(title) {
  return title
    .toLowerCase()
    .normalize('NFKD').replace(/[\u0300-\u036f]/g, '') // strip accent marks: é -> e
    .replace(/[^a-z0-9]+/g, '-')                       // anything else becomes a hyphen
    .replace(/^-+|-+$/g, '');                          // trim leading/trailing hyphens
}
slugify('Café Résumé: My Great Post!'); // -> "cafe-resume-my-great-post"

Using this pattern in your own code

The pattern uses only a character class, +, * and a non-capturing group — all standard, so the text carries over unchanged.

// JavaScript
const SLUG_RE = /^[a-z0-9]+(?:-[a-z0-9]+)*$/;
SLUG_RE.test('hello-world');  // true
SLUG_RE.test('Hello-World');  // false

# Python's re module — identical pattern text
import re
SLUG_RE = re.compile(r'^[a-z0-9]+(?:-[a-z0-9]+)*$')
bool(SLUG_RE.match('abc123-def-456'))  # True

# grep -P, checking every generated slug in a CSV export in one pass
grep -Pv '^[a-z0-9]+(?:-[a-z0-9]+)*$' slugs.csv   # prints every INVALID row

The last example flips the usual sense with grep’s -v flag deliberately: for an audit of already-generated slugs, the useful output is the list of rows that fail the pattern, not the (presumably much longer) list that pass it.

Common mistakes when adapting this pattern

• Making the whole pattern one character class instead of a repeated group. ^[a-z0-9-]+$ looks equivalent at a glance but is not: it happily accepts -leading, trailing- and double--hyphen, because a bare hyphen is just another allowed character with no positional constraint. The non-capturing-group structure on this page ([a-z0-9]+(?:-[a-z0-9]+)*) is what actually rules those three cases out, by requiring a hyphen to always sit between two alphanumeric runs.
• Allowing underscores “to be safe”. Adding _ to the character class accepts my_post alongside my-post, which then means two different-looking URLs can point at conceptually the same slug depending on which one a title was slugified into — a consistency problem more than a validity one. Most platforms standardise on hyphens only and convert underscores to hyphens during generation, rather than accepting both at validation time.
• Validating before slugifying instead of after. Running this pattern against a raw, unprocessed title will reject almost everything, since real titles contain spaces, punctuation and capital letters by default. This pattern is the last step, checking the output of a slugify function (worked example 1 above), not a filter applied to the raw input a person actually types.

Frequently asked questions

Limitations

• ASCII lowercase and digits only; no built-in Unicode support (see the section above for the trade-off and the \p{L} alternative).
• Validates shape only — cannot detect a duplicate slug, which needs a database or lookup check.
• No length limit; add a bounded quantifier or separate length check if your platform needs one.
• Does not generate a slug from a title; pair with a transliteration/normalisation step like worked example 1 for that half of the job.

Related

• Regex to match a URLThe whole link a slug is usually just one segment of
• Regex for an ISO 8601 dateAnother commonly-used building block in dated slugs like 2026-07-22-my-post
• Regex for email validationThe same “shape, not proof” honesty, applied to addresses
• About this toolWhy it exists and how the tester is built
• JSON formatterAnother text tool that runs entirely in your browser
• All toolsSee everything on this site