What this tool does
A slug has one job: be a stable, readable, URL-safe identity for a thing. Getting there is more than a regex, because the order of the steps decides whether you get "cafe" or nothing at all from "café", and whether a Hindi title produces a slug or an empty string. This tool runs a documented RFC 3986 pipeline in the order that works, shows the ASCII byte length as well as the character count, and flags titles that collapse onto a slug another title already owns.
How it works
The first step is a pre-map of the characters that Unicode normalisation will not decompose. ß, æ, œ, ø, đ, ð, þ and ł are letters with no canonical decomposition, so once the string is normalised they are still themselves and then get deleted as non-ASCII, which is how "Straße" silently becomes "strae". They are expanded to ss, ae, oe, o, d, th and l first, while there is still something to read. The same map handles & and @, which become " and " and " at " so that AT&T generates at-and-t rather than welding itself into atandt, and the rupee sign, which becomes rs.
Indic text is transliterated before normalisation, because NFKD leaves Devanagari alone apart from its vowel marks, so without this step the slug is empty. Devanagari, Tamil and Telugu each get a table of independent vowels, dependent vowel signs, consonants and the virama that removes the inherent a. The virama is what handles a conjunct: a consonant followed by the virama suppresses the inherent vowel instead of adding one. This is character-level mapping, not a schwa-aware transliterator, and it gets roughly 90% of conjuncts right. A conjunct it does not know comes out as its parts, and it has no idea that a Hindi word ends in a schwa it did not see, so a slug made this way is a good slug and an important one should still be read aloud by someone who knows the language.
After that comes NFKD, the compatibility decomposition, followed by dropping the combining marks it exposes. That is what turns café into cafe and ñ into n. Non-letters and non-digits then become the separator, runs are collapsed and the ends are trimmed, which is the step that makes the output printable ASCII with no spaces and no percent-encoding needed in a path. Every step is idempotent: running the generator on its own output gives the identical string, because a slug that changes when you re-slug it is a slug that breaks the second time a CMS touches it. The result is checked against a strict ASCII pattern rather than assumed, and the UTF-8 byte length is shown next to the character count, because that is the number a server actually sees.
Truncation cuts on a separator rather than mid-word, so a 60-character cap never produces "the-big-and-beautiful-gui". Stopword removal is available and refuses to reduce a slug to nothing, with a separate short Devanagari list rather than the English one, since "ka" in English and "ka" in Hindi are different words with different meanings. The bulk mode takes a whole list of titles at once and reports collisions instead of resolving them: "Web Design Guide" and "Web-design guide!" both become web-design-guide, and that is reported to you. Appending -2 is the CMS's decision, made with a stable ordering, because a slugifier that does it silently produces URLs that change whenever the order of a listing changes.
Worked example
Generating slugs for a batch of article titles, two of them in Hindi, with a 60-character cap and one guaranteed collision.
- "The Big & Beautiful: A Guide to Café Life — 2026" becomes the-big-and-beautiful-a-guide-to-cafe-life-2026, 47 characters, 47 bytes
- The em dash and ampersand became separators and the word "and", and the é was decomposed by NFKD into e plus a combining accent, which was then dropped
- "Crème Brûlée & Tiramisu: A Café Guide" becomes creme-brulee-and-tiramisu-a-cafe-guide — the è and û both lose their marks the same way
- "भारत में शिक्षा और विज्ञान" becomes bharata-me-shiksha-aur-vijnyana, 31 characters, and the inherent a after each bare consonant is exactly what the schwa-aware transliterator would get wrong
- "AT&T Stock Price: 5 Tips" becomes at-and-t-stock-price-5-tips rather than atandt-stock-price-5-tips
- Bulk mode flags "Web Design Guide" and "Web-design guide!" as both producing web-design-guide, and appends nothing
Six clean ASCII slugs, 47 and 31 of the 60 characters, and one collision reported rather than silently numbered.
Accuracy and limitations
- Indic transliteration is roughly 90% accurate on conjuncts by construction. It is character-level mapping, not a schwa-aware transliterator, so a Hindi or Tamil slug can be readable and still not be the spelling a native writer would choose. Check an important slug before publishing it.
- A distinct title can collapse onto a slug another title already owns, and this tool will not resolve it. Adding a -2 suffix depends on a stable ordering the CMS owns; a slugifier that does it silently produces URLs that change when a listing is reordered.
- The 60-character cap is a character count. If your server, framework or CDN measures the path in bytes, remember the difference matters more for the non-ASCII case — which is exactly why both numbers are reported.
Frequently asked questions
- How do I make a Hindi title into a URL slug?
- Paste it with transliteration switched on. Devanagari, Tamil and Telugu are converted to a roman form before normalisation, otherwise NFKD would strip the vowel marks and leave nothing. Be aware the conversion is character-level and about 90% accurate on conjuncts, so "भारत में शिक्षा" comes out as bharata-me-shiksha, which is close but not always what a Hindi writer would type.
- Why is my slug full of hyphens or empty?
- An all-Indic title with transliteration switched off has nothing for NFKD to decompose and every character is stripped as non-ASCII, so you get an empty string. Turn transliteration on. A title made entirely of punctuation or emoji will always be empty, because there is no alphanumeric content to keep.
- What happens to accented characters and symbols?
- Accented Latin letters are decomposed with NFKD and the combining mark is dropped, so café becomes cafe and ñ becomes n. Letters that normalisation cannot decompose are pre-mapped first: ß becomes ss, æ becomes ae, ø becomes o, and & becomes the word and. A rupee sign becomes rs, and the vulgar fractions are written out as 1-2, 1-4 and 3-4.
- Does the generator guarantee unique slugs?
- No, and deliberately so. It reports which of your titles collapse onto the same slug and leaves it there, because appending a suffix needs a stable ordering that the CMS owns. A slugifier that numbers duplicates silently will hand out URLs that change every time the order of a listing changes, which is worse than a duplicate you can see.
- Does the slug change if I run it twice?
- No. Slugification is idempotent, so the output of the generator is a fixed point: feeding a slug back in returns the same slug. That matters more than it sounds, because a CMS that re-derives slugs on save will otherwise slowly rewrite URLs, and any self-referencing internal link built on the old form starts 404ing.
- What is the 60 character limit for?
- It is a convention for readable URLs, not an HTTP limit, and this tool cuts on a word boundary so a capped slug never ends mid-word. The character count and the UTF-8 byte count are both shown, because the two are the same for ASCII and very different for anything else, and servers and CDNs tend to care about bytes.