Slug Generator
Turn any title or sentence into a clean, URL-safe slug — lowercase, hyphenated, with accents stripped. Free, instant, and works entirely in your browser.
Only ASCII letters and digits are kept — accented characters are converted to their closest plain-ASCII equivalent (é → e, ü → u) rather than dropped, and every other character becomes a separator.
Repeated or leading/trailing separators are collapsed automatically, so punctuation-heavy titles never produce a slug like "--my-title--" or "my--title".
This tool does not check whether the slug is already in use on your site — that check depends on your own CMS or routing table.
The slug is computed live in your browser as you type — your title is never sent to our servers.
Paste the exact page title you plan to publish — the slug updates on every keystroke, so you can see the final URL before you commit to it.
Turning a blog post title, product name, or heading into the URL path a CMS, static site generator, or hand-written route will actually use.
How it works
What is a slug, exactly?
A slug is the part of a URL that identifies one specific page in human-readable words — in https://example.com/blog/best-coffee-shops-berlin, the slug is best-coffee-shops-berlin. It sits between the domain (and any folder structure) and the end of the path, and unlike a database ID or a hash, it is meant to be read, not just resolved. A slug generator takes a title — the kind of string a human writes, with capital letters, spaces, punctuation and sometimes accented characters — and converts it into the constrained, URL-safe form a web server or CMS actually expects.
Why not just use the title as-is?
URLs have real technical constraints a title does not. Spaces are not valid in a URL without being encoded (%20), which is why an unencoded title turns into an ugly string of percent signs the moment it is pasted into an address bar. Many punctuation characters are "reserved" in the URL specification (:, ?, #, &, and others) and carry a special meaning to the browser or server rather than being literal text. And most platforms and style guides also prefer consistently-cased, ASCII-only paths for reasons that go beyond strict necessity — readability, copy-paste safety across terminals and chat apps, and avoiding case-sensitivity bugs on servers that treat /Post and /post as two different pages.
Why hyphens instead of underscores?
Both are valid in a URL path, but they are not treated identically by search engines. Google's own published guidance has, for a long time, recommended hyphens over underscores specifically because Google's indexing treats a hyphen as a word separator (coffee-shop is read as two words, "coffee" and "shop") while an underscore is treated as joining the two words into one token (coffee_shop can be read closer to "coffeeshop"). For a slug meant to be found via search, that difference matters — it is part of why hyphens are the default separator on almost every major blogging platform, e-commerce system, and static site generator today. Underscores still show up in older systems, file-naming conventions, and a handful of CMSes that standardized on them early, which is why this tool supports both rather than forcing hyphens.
How diacritics and accented characters are handled
A title like "10 Best Cafés in München" contains characters — é, ü — that are valid Unicode text but not part of the plain ASCII range most URL conventions expect. This tool does not simply delete them, which would turn "Café" into the confusing "Caf". Instead it uses Unicode NFD normalization to decompose each accented character into its base letter plus a separate "combining mark" (é becomes e + ◌́), then strips the combining marks, leaving the closest plain-ASCII letter: é → e, ü → u, ñ → n, ç → c. The result reads naturally and stays searchable, rather than silently dropping information.
What happens to punctuation, numbers, and repeated spacing?
Any character that is not a plain ASCII letter or digit — after the diacritic step above — becomes a word boundary. Commas, colons, parentheses, ampersands, multiple consecutive spaces, and even multiple consecutive punctuation marks in a row all collapse down to exactly one separator between the words on either side of them, and any separator that would otherwise land at the very start or end of the slug is trimmed off entirely. That means a heavily punctuated title like "React.js Tutorial: Part 1!!" produces a clean react-js-tutorial-part-1, not react-js-tutorial--part-1- or a slug with a trailing hyphen. Digits are preserved as ordinary characters, since numbers (version numbers, years, "Part 1") are common and meaningful in real titles.
Should a slug be lowercase?
Almost always, yes — this is the tool's default. Most web servers and most CMS routing layers are effectively case-sensitive at the file-system or database level even though URLs are conventionally written and shared in lowercase, so a mixed-case slug creates a real risk: /My-Post and /my-post may resolve to two different pages, or one may 404, depending on the exact platform. Consistently lowercase slugs sidestep the whole class of bug. The lowercase toggle exists for the rare case where a platform specifically expects preserved casing (some documentation-generator tools, for instance, mirror a file's exact original name) — check your own platform's convention before turning it off.
What this tool does not do
A slug generator can only work from the text you give it — it has no way to know what other pages already exist on your site. It will not tell you if best-coffee-shops-berlin is already taken by another post, and it will not automatically append -2 to make a duplicate unique the way some CMS platforms do behind the scenes. It also does not truncate long slugs to a maximum length; if you want a shorter URL for a long title, trim the title itself before generating the slug, or edit the result afterward — a slug is meant to be a close, readable match to its title, not a truncated hash, so an editorial judgment call is usually better than an automatic cutoff.
A quick reference for picking your settings
- Publishing a blog post, product page, or documentation page? Hyphen separator, lowercase on — the default almost every modern platform expects.
- Working with a legacy system or a specific style guide that already uses underscores? Switch the separator; everything else about how words are split stays identical.
- Naming a file rather than a URL path? The same slug generally works for a filename too, as long as your operating system and any tooling you use tolerate hyphens or underscores in filenames (nearly all do).
Everything above runs the moment you type — nothing is uploaded, logged, or stored, so pasting a draft title before it is publicly announced is safe from this page's side.
FAQ
What is a URL slug?
The human-readable part of a URL that identifies one specific page — in example.com/blog/best-coffee-shops-berlin, the slug is best-coffee-shops-berlin. It sits after the domain and any folder structure, and unlike a database ID, it is meant to be read.
Should I use hyphens or underscores in a slug?
Hyphens, in almost every case. Google's own published guidance treats a hyphen as a word separator (coffee-shop reads as two words) but an underscore as joining words together (coffee_shop reads closer to one word) — hyphens are also the default on nearly every modern blogging platform and CMS.
Why does my slug turn "café" into "cafe" instead of dropping the é?
The tool decomposes each accented character into its base letter plus a separate accent mark, then removes just the accent mark — so é becomes e, ü becomes u, and so on, rather than deleting the letter entirely and leaving a gap or a missing word.
Why are my repeated hyphens or punctuation collapsed into one?
Every run of non-letter, non-digit characters — commas, colons, multiple spaces, multiple punctuation marks in a row — is treated as a single word boundary, not one separator per character. That is what turns "React.js Tutorial: Part 1!!" into react-js-tutorial-part-1 instead of a slug full of doubled-up hyphens.
Should a slug always be lowercase?
Almost always. Most servers and CMS routing are effectively case-sensitive even though URLs are conventionally shared in lowercase, so a mixed-case slug risks two different pages (or a broken link) for what should be the same URL. Turn the lowercase toggle off only if your specific platform expects preserved casing.
Does this tool check if the slug is already taken on my site?
No — it has no knowledge of your site's other pages. Checking for and resolving duplicate slugs (often by appending "-2") is something your CMS or routing layer handles, not something a standalone text tool can know about.
Does it limit the slug to a maximum length?
No. If you want a shorter URL, trim the source title before generating the slug, or edit the result — an automatic character-count cutoff can end mid-word and produce a confusing, un-readable slug, so this is left as an editorial choice.
What happens to numbers in my title?
They are kept as ordinary characters, since version numbers, years, and phrases like "Part 1" are common and meaningful in real titles. Only non-alphanumeric characters are treated as separators.
Can I use this for a filename instead of a URL?
Generally yes — the same rules (lowercase, hyphen- or underscore-separated, ASCII-only) that make a good URL slug also make a safe filename on nearly every operating system.
Is my text uploaded anywhere?
No. The slug is computed entirely in your browser as you type. Nothing is uploaded, logged, or stored, so pasting an unpublished title or a draft product name is safe from this page's side.