← Back to all posts Explainer

URL slugs: what they are and how to write one that lasts

May 28, 2026·7 min read

Every URL on the web has a slug: the human-readable tail of the path that names a single page. Content systems produce a slug automatically from the page title, but the small choices in how that slug is shaped affect how it reads, how easy it is to share, and how often it has to be changed later. This post walks through what a slug is, the rules every slug follows, the choices that are actually yours to make, and the habits that keep a slug useful for years instead of months.

The anatomy of a URL

Take a typical address:

https://example.com/blog/how-to-bake-sourdough

It breaks into four parts:

The slug is the part the writer has the most direct say over. Everything else is decided by hosting setup, the routing in the content system, and the directory the page lives in. The slug is the name of the page itself.

The short version

A good slug is:

The same five points cover almost every style guide that has ever been written about slugs.

The rules every slug follows

The first set of rules are not opinions. They are imposed by the URL specification (RFC 3986) and by the way browsers, mail clients, and chat apps render links.

1. Only safe characters

A URL path can contain letters, digits, and a short list of safe punctuation: -, _, ., and ~. Anything outside this set has to be percent-encoded, which turns a clean readable URL into something like /blog/caf%C3%A9-au-lait. The slugifying step replaces the unsafe characters before the URL ever ends up in a link.

2. No spaces

Spaces in a URL are written as %20 in HTML form, but every link preview tool wraps them, copies them oddly, or breaks them across lines. The convention is to replace each run of whitespace with a single hyphen.

3. Lowercase

URL paths are technically case-sensitive on the server side, which means /About and /about can resolve to different pages. To avoid surprise duplicate-content situations, almost every site lowercases the slug before it is saved. Mixed-case URLs also look inconsistent next to one another in lists, sitemaps, and search results.

4. No diacritics in the typical case

Letters with accents (é, ñ, ö) are valid in modern URLs, but many older clients still mangle them and some indexing tools count the encoded form as a different URL than the plain form. The common compromise is to decompose accented letters to their ASCII base (é → e) before saving. Some sites running in non-Latin scripts keep their native characters; that is a deliberate choice and is fine when the audience supports it.

5. No emoji or punctuation

Emoji and punctuation marks all encode to long sequences and add no descriptive value. They are stripped along with spaces.

The choices that are actually yours

Once the rules above are applied, several smaller decisions remain. None of them are wrong; the consistency of choosing one and sticking with it matters more than which one is picked.

Hyphen or underscore

The hyphen is the most common separator and reads naturally in long URLs. The underscore is sometimes preferred inside file names but is less common in path slugs. Either is parseable by every modern search engine and URL handler. Pick one and stay with it across the whole site.

Short or descriptive

A slug like /post-1234 is short, but it tells no one what the page is about. A slug like /the-complete-and-definitive-2026-guide-to-bread-baking-for-absolute-beginners describes the page but is unmanageable in a tweet, a print citation, or an email signature. The middle ground is three to seven words that name the topic clearly.

Stop words

Small words like a, the, and, of, to rarely add meaning to a slug. Many sites drop them; some keep them because the slug reads more naturally with them in. The difference is cosmetic. The slug guide-to-bread-baking and guide-bread-baking point at the same page.

Numbers and dates

A date in a slug (/2026/05/how-to-bake-sourdough) is helpful when content is news-like and the freshness matters. It is unhelpful when the content stays accurate for years, because the date in the URL ages even when the article does not. Year-only is a common middle ground.

The page title verbatim or a slug-only version

A blog post titled "How to bake sourdough (a 2026 update)" can slugify to how-to-bake-sourdough-a-2026-update or be hand-shortened to sourdough-baking-guide. The first preserves the title; the second is shorter and more durable. Both are fine choices for different content systems and editorial styles.

One small habit

The slug is usually the easiest part of a URL to forget about. Setting a clear convention once and writing it down somewhere visible to the team is the cheapest way to keep the next hundred slugs consistent without anyone having to think about it each time.

Common mistakes

Keyword stuffing

A slug like /best-cheap-fast-easy-sourdough-bread-baking-guide-2026 packs every search term into one place. Modern crawlers see through it and the URL itself becomes harder to read or share. A clean three-to-five word slug describing the actual page tends to do the job better and ages better.

Auto-generated meaningless slugs

Some content systems produce slugs like /?p=4192 or /post/abcde12345 by default. These work technically, but they remove every signal a reader (or a sharing tool, or a generated link preview) could pick up. Setting up the system to produce a slug from the title once is a small task that pays off forever.

Changing slugs without redirects

The single most common pain point with slugs. Editorial teams rename pages, redesign URL structures, or move content into new folders, and the old URL ends up returning a 404. Inbound links break, bookmarks fail, and the page loses the signal it had built up. The fix is simple: any slug change should be paired with a 301 redirect from the old path to the new one.

Mixing separators on the same site

Half the slugs use hyphens, the other half use underscores, a few have stray uppercase letters. This usually happens during migrations or when different teams own different sections. A one-time audit and a redirect map fixes it.

What about Unicode slugs?

Modern URL specifications (IRI / RFC 3987) allow non-ASCII characters directly in URLs. Browsers display them in their native form but encode them as percent sequences when sharing. Sites publishing in non-Latin scripts often keep the original characters; this is a fully supported choice in current browsers and search engines, and it preserves the link's meaning to readers.

The catch is that some older systems (legacy email clients, some scraping tools, some content moderation pipelines) still mangle the encoded form. For sites with an international audience this is rarely a problem; for systems that need to round-trip through older infrastructure, the ASCII-folded form is the safer default.

How the slug is generated, step by step

A slugifier doing a clean job runs the title through roughly this sequence:

  1. Optionally normalise accented characters and drop their diacritics
  2. Optionally lowercase the whole string
  3. Replace every run of non-letter, non-digit characters with the chosen separator
  4. Collapse repeated separators down to one
  5. Trim any separator left at the very start or end
  6. Optionally truncate to a maximum length, removing any separator left dangling at the cut

Every step is deterministic, so the same title with the same options always produces the same slug.

Generate slugs from one title or a whole spreadsheet

Free, runs in your browser, supports hyphens, underscores, accent stripping, and a length cap.

Open the generator →

What this post is not

It is not a promise that any particular slug style will rank better. Crawlers and ranking systems weigh hundreds of signals, and the slug is one small input among them. A clearly written slug is a courtesy to readers and a small consistency signal to indexing tools; the rest of the work that goes into a page matters more.

It is not a single rulebook that every site has to follow. Different content systems, audience languages, and editorial cultures will pick different conventions. A travel site publishing in Japanese, a developer blog in English, and a recipe site in French will end up with three different slug styles, all of them defensible.

It is not a substitute for editorial judgement. Two writers can take the same title and produce different slugs that both feel right. As long as the rules above are respected and the choice is consistent across the site, both slugs are doing their job.

It does not cover every system's quirks. Some platforms add slug suffixes when two titles collide. Some support custom routing on top of the default slug. Some treat trailing slashes as different URLs. Those details belong to the documentation for each platform; the conventions above are the layer that sits underneath all of them.

Related reading