Slug Generator

The tool runs a short, predictable pipeline over your input:

1. Lowercase the whole string, so My Post and my post produce the same slug.
2. Normalize accented characters to their ASCII base where possible, so Café becomes cafe and naïve becomes naive.
3. Replace any run of non-alphanumeric characters (spaces, punctuation, symbols, emoji) with a single hyphen.
4. Collapse repeated hyphens into one, so a -- b doesn't yield a---b.
5. Trim leading and trailing hyphens, so a title ending in ? doesn't leave a dangling -.

The result only ever contains a-z, 0-9, and -. That character set is safe in a URL path without percent-encoding and works equally well as a filename on every common operating system. Because the steps are deterministic, the same title always produces the same slug, which matters when you need stable, reproducible links.

Suppose you're publishing an article titled:

How to Deploy Node.js in 2024 — A Beginner's Guide!

Walking through the pipeline:

• Lowercase: how to deploy node.js in 2024 — a beginner's guide!
• The . in node.js, the spaces, the em dash, the apostrophe, and the ! are all non-alphanumeric, so each run becomes a hyphen.
• Collapse and trim the hyphens.

Final slug:

how-to-deploy-node-js-in-2024-a-beginner-s-guide

Notice two things. node.js becomes node-js, not nodejs, because the dot is treated as a separator rather than removed. And beginner's becomes beginner-s, because the apostrophe is also a separator. If you'd rather have beginners or nodejs, edit the title before generating, or tidy the slug afterward. Slug generation is intentionally conservative: it never guesses which characters you meant to keep, it just guarantees the output is valid.

Slugs show up anywhere a name needs to become a stable identifier:

• Blog and CMS permalinks — turning a post title into the /blog/<slug> segment.
• Static site routes — generating page paths in frameworks that map files to URLs.
• Filenames — naming exports, assets, or generated documents so they sort predictably and survive being copied between systems.
• API resource identifiers — when you want a readable key (/projects/internal-dashboard) instead of a numeric ID.
• Anchor IDs — converting section headings into id attributes for in-page links.
• Branch or ticket names — collapsing a feature description into something git-friendly.

The common thread is wanting a value that is readable by a human, safe in a URL or path, and identical every time it's derived from the same source string.

A few things that trip people up:

• Slugs aren't unique by themselves. Two different titles can collapse to the same slug (for example C++ and C both reduce toward c). If you store slugs as keys, add a uniqueness check and append a counter like -2 when a collision happens.
• Numbers survive, but the meaning can drift. Top 10 becomes top-10, which is fine, but a title that's only symbols (like !!!) reduces to an empty string. Have a fallback ready.
• Editing a published slug breaks links. Once a URL is live and indexed, changing its slug returns a 404 for anyone holding the old link. Set up a redirect if you must rename.
• Non-Latin scripts mostly drop out. Characters that have no ASCII equivalent are removed, so a fully Cyrillic or CJK title can yield an empty slug. For those cases you'll want a transliteration step before slugging.

URLs have a defined grammar. The path segment allows unreserved characters (A-Z a-z 0-9 - . _ ~) directly; anything else must be percent-encoded, so a space becomes %20 and an accented é becomes a multi-byte %XX%XX sequence. Encoded URLs still work, but they're ugly to read, easy to mangle when copied into chat or email, and inconsistent across tools that encode differently.

By restricting output to lowercase letters, digits, and hyphens, a slug sidesteps all of that. The hyphen is the conventional word separator because it's unreserved and search engines treat it as a word boundary, whereas underscores are sometimes read as joining two words. Lowercasing matters too: URL paths are case-sensitive on most servers, so My-Page and my-page can resolve to different resources. Forcing lowercase removes a whole class of "works on my machine" bugs where a link breaks only because someone typed a capital letter.