Slug Generator — URL-Friendly Slugs from Any Text

What a URL slug is

A slug is the human-readable part of a URL that identifies a page. If the URL is example.com/blog/2026-rust-tutorial, the slug is 2026-rust-tutorial. Slugs matter because they appear in search results, they get shared in links, and they show up in every bookmark — they are, in a real sense, the permanent address of your content.

Generating a good slug from a title takes more than lowercasing it and swapping spaces for hyphens. You have to handle diacritics, quotes, emoji, non-Latin characters, punctuation, stop words, length limits, and edge cases like titles that start with a number or end with a quote. This tool does all of that, with four presets that cover 95% of real-world needs.

Rules of a good slug

• Readable to humans: a slug is not an ID. Someone scanning a URL should be able to guess what the page is about from the slug alone
• Short: URLs get truncated in search results at around 60–70 characters. If the slug is longer, Google cuts it off with an ellipsis and readers only see the first few words
• Hyphen-separated: Google explicitly recommends hyphens over underscores for word boundaries. Underscores get treated as part of a single token (foo_bar = one word to Google, foo-bar = two words)
• Lowercase: URLs are technically case-sensitive, but mixed-case slugs cause confusion when users type them. Normalize to lowercase
• ASCII-safe by default: even though modern browsers handle non-ASCII URLs via IRI/punycode, many sharing tools, email clients, chat apps, and analytics systems still mangle them. Safest to stick to ASCII unless you specifically need non-Latin slugs
• Stable: once a slug is published, changing it breaks every inbound link. Pick a slug you can live with

The four presets explained

Default (GitHub-style)

Lowercase, hyphen-separated, strip diacritics, strip non-ASCII. This is what GitHub uses for README anchor links, what most static site generators default to, and what WordPress produces if you don't customize. Safe everywhere — good starting point for blogs, documentation, product pages.

"The Beginner's Guide to Rust — 10 Things I Wish I'd Known"
  → the-beginners-guide-to-rust-10-things-i-wish-id-known

SEO-optimized

Same as default plus: drop English stop words (the, a, of, in, on, to…) and cap the length at 60 characters. The stop word removal shortens slugs while keeping the meaningful keywords that Google's ranking cares about. The 60-char cap matches Google's typical SERP truncation point.

"The Beginner's Guide to Rust — 10 Things I Wish I'd Known"
  → beginners-guide-rust-10-things-wish-id-known

Caution: aggressive stop-word removal can make slugs awkward to read ("Best Places Visit Tokyo" vs "Best Places to Visit in Tokyo"). The stop word list here is deliberately small to avoid this. If readability matters more than keyword density, use the Default preset instead.

Unicode-safe

Keeps non-Latin characters intact. Use when your CMS and target audience support IRI (Internationalized Resource Identifiers) — mostly East Asian, Arabic, and Cyrillic markets where native-script URLs have become common.

"入门 Rust 2026 — 十件我希望早就知道的事"
  → 入门-rust-2026-十件我希望早就知道的事

Most major CMSes (WordPress 5.5+, Ghost, Hugo, Next.js dynamic routes) handle IRI URLs correctly, but some legacy systems and analytics tools still stumble on them. Test before committing.

Filename-safe

Lowercase, underscore-separated. Good for filenames in shell scripts, Python modules, CI artifacts, and anywhere hyphens get interpreted as flags or operators. Google does not see underscores as word boundaries, so avoid this preset for URLs meant to rank in search.

"Q4 2026 Revenue Report — Final Version"
  → q4_2026_revenue_report_final_version

How this tool works

1. Unicode normalization: the input is decomposed with String.prototype.normalize("NFD"). This splits characters like é into their base letter (e) plus a combining acute mark (U+0301)
2. Diacritic stripping: if enabled, the combining marks (U+0300–U+036F) are removed with a regex, leaving clean ASCII letters
3. Non-ASCII stripping: if enabled, anything outside \x00-\x7F is removed (CJK, emoji, Greek, Cyrillic, etc.)
4. Case normalization: lowercase, preserve, or uppercase applied
5. Tokenization: the string is split on any non-letter, non-digit character into words. When non-ASCII is preserved, the tokenizer uses Unicode property escapes (\p{L}\p{N}) so CJK characters count as letters
6. Stop word filtering: if enabled, common English stop words are dropped before joining
7. Join with separator: tokens joined with the chosen separator (hyphen, underscore, or dot)
8. Length truncation: if a max length is set, the slug is cut at the last separator before the limit — never mid-word — so it reads cleanly even when truncated

Real examples of what gets normalized

"Café & Bistro — 5★ Reviews!"
  → cafe-bistro-5-reviews              (default)
  → cafe-bistro-5-reviews               (SEO — stop words absent)
  → café-bistro-5★-reviews              (Unicode-safe, keeps é and ★)

"10,000 Hours to Mastery (Part III)"
  → 10-000-hours-to-mastery-part-iii    (default)
  → 10000-hours-mastery-part-iii        (SEO — drops 'to', keeps numbers)

"Что такое Next.js?"
  → (empty with strip non-ASCII)
  → что-такое-next-js                   (Unicode-safe)

"🚀 Launching v2.0 Today!"
  → launching-v2-0-today                (default — emoji stripped)
  → launching-v2-0-today                (SEO — same)
  → 🚀-launching-v2-0-today              (Unicode-safe)

Common mistakes

• Using spaces: spaces become %20 in URLs, which is valid but ugly and breaks some chat clients that auto-link URLs. Always convert spaces to hyphens or underscores
• Trailing punctuation: slugs ending in a hyphen look broken ( how-to-code-). This tool trims them automatically — don't manually add them
• Case-sensitive slugs that clash: if your server treats /Foo and /fooas different pages, you'll have duplicate-content SEO issues. Always lowercase
• Stop-word removal going too far: dropping every stop word can produce slugs that are hard to read. best-places-visit-tokyo sounds robotic compared to best-places-to-visit-in-tokyo. The stop-word preset in this tool uses a small list on purpose
• Numbers at the start: URLs starting with a year (like /2026-annual-report) are fine for dated content but bad for timeless content — you'll want to redirect them when the content is updated the following year
• Long slugs: anything over ~80 characters gets truncated in search results, bookmark bars, and social previews. Use the length cap
• Mid-word truncation: truncating at a fixed character count without a word-boundary check produces garbage slugs (the-beginners-guide-to-ru). This tool truncates at the last separator before the cap — never mid-word

Privacy

All string manipulation runs in your browser using native APIs (String.normalize, regex, Unicode property escapes). No text you paste is sent to a server, logged, or cached. Safe for unreleased article titles, product names, and draft content.

Frequently asked questions

Why hyphen over underscore?

Google treats hyphens as word separators ( foo-bar → "foo", "bar") and underscores as part of a single token ( foo_bar→ "foo_bar" — one word). For SEO, hyphens make every word individually rankable. For internal use (filenames, CI artifacts, variable names), underscores are fine — that's what the Filename-safe preset is for.

Should I include the publication year in the slug?

Only if the content is genuinely dated (a year-end retrospective, a year-specific guide that won't be updated). For evergreen content, including the year locks you into a URL that looks stale the next year. Many blogs regret it and have to maintain redirects forever. Default to no year.

What about emoji in slugs?

Technically supported by modern browsers via punycode, but in practice emoji URLs look broken in most analytics, break in some social share previews, and are unreachable if someone has to type them manually. The Default and SEO-optimized presets strip them. The Unicode-safe preset keeps them, but only use it if you're sure your platform handles them correctly end-to-end.

Can I use Chinese / Japanese / Arabic slugs?

Yes, with the Unicode-safe preset. Modern CMSes and browsers fully support non-Latin URLs, and for audiences in those markets, native-script slugs can actually help SEO by matching the user's query language exactly. The caveat is cross-platform sharing — if your content spreads beyond the native-language audience, ASCII slugs round-trip better through email clients, chat apps, and older tools.

How long should a slug be?

Short enough to read in a search result (≤60 chars is safe), long enough to convey the topic (at least 3-4 keywords). The SEO-optimized preset caps at 60, which is a good default. Don't pad slugs with filler words to meet an arbitrary length — shorter and meaningful beats longer and generic.

What if my slug collides with another page?

Most CMSes auto-append a suffix ( hello-world-2) when there's a collision. This tool doesn't know about your existing pages, so collision handling is your CMS's job. Check for collisions before publishing.

Is my data sent anywhere?

No. The slug generation is pure JavaScript running in your browser — no network calls, no analytics on the text you convert, no logging. Safe for unreleased content and private drafts.