Slug Generator — URL Slug & SEO-Friendly Slug Maker Online

RFC 3986 (Berners-Lee, Fielding, Masinter; January 2005, IETF / STD 66) defines the unreserved character set as ALPHA / DIGIT / '-' / '.' / '_' / '~' — anything outside that range must be percent-encoded as UTF-8 octets. Modern browsers and servers support Unicode URLs via percent-encoding (so 'café' becomes '%C3%A9' in the path), but the percent-encoded form is hard to read, hard to share verbally, copy-paste fragile across some terminals and email clients, and inconsistently handled by CMSes and analytics systems. ASCII slugs avoid the issue entirely — they survive every encoding boundary, render identically everywhere, and stay short. For internationalized content, modern CMSes typically combine an ASCII slug with a separate Unicode title field rather than encoding the title into the URL itself.

Each pass — lowercase, NFD normalize, strip combining diacritics (U+0300–U+036F), strip non-ASCII-alphanumeric, collapse whitespace and hyphens — is itself idempotent. NFD normalize on already-decomposed text is a no-op; lowercase on already-lowercase ASCII is a no-op; the regex strips have nothing left to remove on a second pass. So `slugify(slugify(x)) === slugify(x)` for all inputs. Idempotency matters for systems that may slugify the same input twice (CMS save → re-render → re-slugify), URL canonicalization (a slug fetched from the database and re-validated should produce itself), and migrations (re-running a slug-generation pass over already-slugified data must be safe).

NFD canonical decomposition splits characters with a canonical mapping to base + combining marks — primarily Latin, Greek, Cyrillic, and Vietnamese precomposed letter+diacritic forms. CJK ideographs and most Arabic letters are atomic in Unicode and have no canonical decomposition. Korean Hangul precomposed syllables (U+AC00–U+D7A3) DO canonically decompose into Jamo (U+1100–U+11FF) per UAX #15 §10.1 — but those Jamo are then dropped by the next pass — strip everything outside [a-z0-9 -] — so the practical result is the same: '東京', '서울', or 'مرحبا' produce an empty slug, which many CMSes (WordPress, Ghost) fall back to a record ID for. For real internationalized slugs, ICU transliterators (Latin-ASCII transform) or romanization libraries (Hepburn for Japanese, Pinyin for Chinese, Revised Romanization for Korean) provide phonetic ASCII renderings — those are out of scope for a deterministic stripped slug.

case-converter's kebab-case applies the same NFD plus combining-diacritic strip step but keeps every alphanumeric character in the result, then joins word boundaries with hyphens — so 'Hello World 2025!' becomes 'hello-world-2025!' (keeps the digits and the trailing exclamation if there's no further filter). slug-generator additionally drops everything that isn't a lowercase ASCII letter, digit, whitespace, or hyphen — so the same input becomes 'hello-world-2025'. The slug is more conservative because URL safety is the constraint, while case-converter's kebab is for code identifiers where 2025 is a fine variable-name component.

The slug output region is marked aria-live="polite", the W3C WCAG Success Criterion 4.1.3 (Status Messages, introduced in WCAG 2.1, Recommendation 5 June 2018; carried unchanged into WCAG 2.2, Recommendation 5 October 2023) pattern. Polite live regions queue announcements after any speech in progress, so editing the title announces the new slug without interrupting the user mid-sentence. Screen readers (NVDA, JAWS, VoiceOver) consume the live region automatically; nothing else is required from the user.