Text to Slug Converter
Turn any text into a clean, URL-friendly slug instantly, perfect for blog post URLs, filenames and IDs.
About the Text to Slug Converter
Any piece of text becomes a clean, URL-safe slug: lowercased, stripped of accents (café becomes cafe), with spaces and punctuation swapped for the separator you pick. Handy for generating blog post URLs, file names, or database-friendly identifiers straight from a title.
Accent removal works for é and ö, but not for ø, ß, or æ
Accent stripping runs through normalize("NFD") followed by deleting any combining mark in the Unicode range it decomposes into, which correctly turns "café" into "cafe" and "Björk" into "bjork" because those accented letters are, under the hood, a plain base letter plus a separate mark that NFD can split apart. But a handful of letters — ø, ß, æ, œ, and a few others — aren't built that way in Unicode; they're their own standalone characters with no combining-mark decomposition at all. This tool doesn't have a fallback table for those the way this site's dedicated Remove Accents/Diacritics tool does, so instead of being transliterated to their closest plain-letter equivalent, they simply get treated as non-alphanumeric characters and swapped out for the separator. A title like "Café øre straße" comes out as "cafe-re-stra-e," not "cafe-ore-strasse," since the ø and ß are deleted from the wording entirely rather than spelled out.
Why the accent-stripping step has to run before the alphanumeric filter, not after
The order here matters in the same way it does on several other tools on this site: NFD decomposition and mark removal happen first, and only afterward does the pattern /[^a-zA-Z0-9]+/g replace everything that isn't a plain letter or digit with the separator. Running it in the opposite order would break accent handling entirely, since a raw character like é isn't a plain a-z letter to begin with — if the alphanumeric filter ran first, é would simply be treated as "not alphanumeric" and deleted outright, the same fate as ø and ß get now, rather than being decomposed into "e" first and correctly kept.
Leading and trailing separators are actively trimmed off
Text starting or ending with punctuation, like "-Hello World-" or a title that begins with a quotation mark, would otherwise leave a stray leading or trailing separator character sitting at either end of the slug. A dedicated cleanup step specifically strips any separator characters found at the very start or end of the result after everything else has been converted, which is what keeps a slug generated from oddly-punctuated input looking clean rather than starting or ending with a dangling hyphen or underscore.
Multiple separators rarely, if ever, need collapsing given how the conversion works
The code includes a step that specifically collapses two or more consecutive separator characters down to one, using a dynamically built regex. In practice, this rarely has anything to do: the earlier step that replaces non-alphanumeric characters with the separator, /[^a-zA-Z0-9]+/g, already matches an entire consecutive run of punctuation and spacing in one go and swaps the whole run for a single separator character, so two separator instances essentially never end up sitting directly next to each other in the first place for the collapse step to find and clean up. It's a reasonable defensive step to have in the code regardless, just one that the algorithm's own design makes largely redundant in normal use.
Why the separator itself gets escaped before being used in a regex
Both the collapse-duplicates step and the trim-the-ends step build a fresh regular expression out of whatever separator character is currently selected, and before doing so, the code escapes any regex-special characters in that separator with sep.replace(/[.*+?^${}()|[\]\\]/g, "\\$&"). Neither of the two separators this tool currently offers, a hyphen or an underscore, actually carries special meaning as a bare regex pattern, so this escaping step doesn't change behavior for the options available today — but it's the correct, safe way to build a regex from a variable value in general, and it means the underlying slugify() function would keep working correctly if a third, more unusual separator option were ever added to the dropdown in the future.
Frequently Asked Questions
Does this convert every accented or special letter to its plain equivalent?
Not all of them. Letters that Unicode represents as a base letter plus a separate accent mark, like é or ö, are correctly converted to their plain form. But letters that are their own standalone character with no such decomposition, like ø, ß, and æ, are removed entirely rather than transliterated, since this tool doesn't include a fallback table for those specific characters.
Why does "straße" turn into "stra-e" instead of "strasse"?
The German ß (sharp S) doesn't decompose into a base letter plus an accent mark the way é does, so it isn't recognized by the accent-stripping step. It gets treated as a non-alphanumeric character and replaced with the separator instead of being spelled out as "ss."
Can my slug end up with a leading or trailing hyphen?
No. A cleanup step specifically removes any separator characters left at the very start or end of the result, so text that starts or ends with punctuation won't produce a slug with a dangling separator at either end.
What happens if I turn off "Convert to lowercase"?
The letter casing from your original text is preserved in the slug instead of being forced to lowercase. Accent stripping and separator handling still work the same way regardless of this setting; it only controls whether letters keep their original case.
Is my text sent to a server when I use this tool?
No. The slug is generated entirely in your browser as you type; nothing is uploaded anywhere.