Testing a URL-Slug Pattern

Testing a URL-Slug Pattern Against a Batch of Candidates

A slug generator that mostly works is worse than one that obviously does not, because the failures only show up once a stray capital letter or double hyphen ships into a live URL. Pinning down exactly what counts as a valid slug, lowercase letters and digits, single hyphens as separators, nothing else, before that pattern reaches a routing layer or a database constraint, catches the failure while it still costs nothing to fix.

What a strict slug pattern actually needs to enforce

A URL slug has a narrower job than most strings a validator checks: lowercase letters, digits, and single hyphens used only as separators between words, with no leading, trailing, or doubled hyphen anywhere in the string. Letters, digits, hyphens, and a small handful of other characters are the "unreserved" set the URI specification exempts from percent-encoding, which is exactly why a slug built only from that set survives every URL context untouched.¹ That narrowness is exactly what makes it worth testing carefully, since a pattern that is slightly too permissive can let a genuinely broken slug slip straight through into a URL.

The tester's built-in URL slug snippet, available from the Snippets menu, encodes that rule as ^[a-z0-9]+(?:-[a-z0-9]+)*$. Anchored at both ends so a partial match at the start or end of a string cannot pass, the pattern reads as one or more lowercase alphanumeric characters, optionally followed by any number of hyphen-plus-alphanumeric groups. A capital letter, a leading hyphen, or two hyphens in a row all break that structure and correctly fail the match. The same lowercase-letters-digits-hyphens shape shows up well beyond URL slugs; Google Cloud's own resource-naming rules for Compute Engine require names to match a near-identical pattern, since infrastructure identifiers and SEO-friendly slugs both converge on the same practical, encoding-safe character set.²

Checking one candidate at a time in Match mode

Before committing to a batch of test cases, pasting a single candidate slug into the test text field and watching whether it highlights confirms the pattern behaves the way you expect on an obvious case. my-product-name should highlight as a full match; My-Product-Name should not, since the pattern has no case-insensitive flag active by default, and the engine only folds letter case when that flag is explicitly turned on.³ That quick check takes seconds and catches an obviously wrong pattern before you invest time building out a larger batch of edge cases around it.

Moving from one check to a whole batch with Unit Tests mode

Checking slugs one at a time in Match mode works for a quick sanity check, but a slug generator needs to handle dozens of edge cases correctly, not just the one you happened to think of first. Unit Tests mode is built exactly for that shift: each row holds one candidate string and an explicit should-match or should-not-match expectation, and every edit to the pattern re-runs the entire batch at once.

Building a batch that actually exercises the edge cases

A useful test batch for a slug pattern includes the obvious positive case, my-product-name, alongside the specific failures that matter most: a version with a capital letter, a version with a leading hyphen, a version with a trailing hyphen, and a version with a doubled hyphen from a bad string-replace somewhere upstream. Marking each row's expectation correctly and watching the pass count update live turns "the pattern looks right" into a verified claim backed by five or six concrete assertions.

Every PASS or FAIL badge sits directly next to its row, so a single failing case among a dozen passing ones is immediately visible rather than buried in a wall of text output. That visibility is what makes Unit Tests mode faster than re-reading the pattern by eye once your test batch grows past two or three candidates.

Deciding what happens to a slug that fails validation

A validation pattern only tells you a candidate string is invalid; it does not fix it. Most slug pipelines pair this kind of check with a normalization step upstream, lowercasing the input, replacing spaces and punctuation with single hyphens rather than underscores, since search engine crawling guidance specifically recommends hyphens as word separators over underscores, and trimming any leading or trailing hyphen the replacement step introduced, so that a failure here is rare in production rather than routine.⁴

Treating a validator failure as a signal about the pipeline

If your validator is failing regularly on real user-submitted titles, that is usually a sign the normalization step upstream needs work, not that the validation pattern itself is too strict. Test the normalized output against this pattern, not the raw title text a user actually typed, since the two are supposed to represent different stages of the same pipeline and testing the wrong one gives you a misleading picture of where the real problem sits.

When to use this

Use this guide when you need to validate a lowercase, hyphen-separated slug pattern against a batch of candidate strings before wiring it into a routing layer or database constraint.

Examples

Pattern: ^[a-z0-9]+(?:-[a-z0-9]+)*$
Test strings: my-product-name, My-Product-Name, -leading-hyphen, double--hyphen

my-product-name is marked should match and passes. The other three are marked should not match and all correctly fail, for a pass count of 4 of 4.