Slug-generator

Turn any title into a clean, SEO-friendly URL slug

A slug generator turns a page title or any text into the short, lowercase, URL-safe string that names a page — the part after the last slash in an address. Type a title and this URL slug generator builds the slug live: it lowercases the text, swaps spaces for hyphens, transliterates accented letters, strips punctuation, and collapses repeated separators into one clean hyphen.

So 'My First Blog Post!' becomes my-first-blog-post instantly, ready to copy. There's nothing to install and no account to create — paste a title, tweak the options, and grab the result. The preview updates with every keystroke, showing the finished slug inside a sample URL so you can see exactly how it will look in an address bar.

What makes a slug good for SEO

A good slug is short, readable, and built around your main keyword. Search engines show the slug in results and use it as a ranking signal, so clarity matters more than completeness. Keep it lowercase, separate words with hyphens — not underscores, which Google reads as joining two words rather than separating them — and cut the filler.

Turn on Remove stop words to drop words like a, the, of and to automatically — 'The Best Tips for a Healthy Diet' becomes best-tips-healthy-diet, a tighter, more SEO-friendly slug. Keep slugs under 60 characters where possible. Set a max length to trim long titles to a whole word so you never end up with a broken fragment like how-to-bake-cre.

Accents, symbols, and non-English text

Plain ASCII is the safe alphabet for URLs, so anything outside a–z, 0–9 and the hyphen needs to be handled. This slugify tool transliterates accented characters to their nearest ASCII match — é→e, ñ→n, ü→u, ç→c — and expands letters that have no single equivalent: ß→ss, æ→ae, ø→o.

'Niño Piñata Soirée' becomes nino-pinata-soiree. Symbols are removed, and an optional toggle rewrites & as and, so 'Salt & Pepper' becomes salt-and-pepper instead of silently dropping the word. For languages like Chinese or Arabic with no direct transliteration, most CMS platforms handle localised slugs natively — this tool focuses on the Latin-script case where accents are the main problem.

Bulk slug generation and format options

Need more than one slug? Switch to Bulk mode, paste a list of titles — one per line — and the bulk slug generator returns one slug per line. Copy them all or download a .txt file. Every option you've set (stop-word removal, separator, max length, lowercasing, ampersand expansion) applies consistently across the entire batch.

It's practical for migrating a blog to a new CMS, seeding a content calendar with planned permalink structures, or generating slugs from a list of product names before the pages are built. No rate limits, no subscription, and no upload — the whole batch runs locally in your browser, so even hundreds of titles process in under a second. Choose a hyphen or underscore separator, set a max length to keep permalinks tidy, or keep capitals if your platform needs them.

How this compares to it-tools.tech, 10015.io, and other slug generators

Most free online slug tools cover the basics: lowercase, replace spaces with hyphens, strip punctuation. it-tools.tech and 10015.io both do this, but neither offers stop-word removal, a configurable separator, or bulk mode. GoToolsOnline adds a few options but still requires a page reload for each conversion. Dedicated libraries like slugify (npm) and python-slugify are more capable but require writing code.

This tool sits between the two: it handles accent transliteration, stop-word filtering, separator choice, max length, and ampersand expansion through a live UI without installing anything. Bulk mode covers the gap for anyone who needs to process a list. And because everything runs client-side in your browser, pasting unpublished page titles carries no privacy risk — no title is sent to any server or logged anywhere.

URL anatomy and RFC 3986: what goes where in an address

A URL has five parts defined by RFC 3986, the Internet standard that governs how web addresses are structured: the scheme (https://), the authority (example.com), the path (/blog/my-post), an optional query string (?ref=home), and an optional fragment (#comments). The slug lives in the path — the portion that identifies the specific resource on the server.

RFC 3986 defines a set of unreserved characters that are safe to include in any part of a URL without percent-encoding: the 26 uppercase and 26 lowercase ASCII letters, the digits 0–9, and the four symbols hyphen (-), underscore (_), period (.), and tilde (~). Everything else — spaces, accents, &, ?, #, / used outside their delimiter role — must be percent-encoded into a %XX hex sequence. A space, for example, becomes %20. Note that the plus sign (+) is not a universal space substitute: it represents a space only inside application/x-www-form-urlencoded query strings (HTML form data), not in URL paths. Writing a path like /my+blog+post is technically incorrect outside query context and may confuse servers that parse the path literally.

Browser URL length limits are also worth knowing when building long paginated or filtered URLs. Internet Explorer capped URLs at 2,048 characters; modern Chrome and Firefox handle up to roughly 8,192 characters before truncating. For slugs specifically, the constraint is not the browser but the search engine snippet: Google typically shows 60–70 characters of a URL in the results page, so slugs longer than that get cut off in the display even when they technically function.

Hyphens vs underscores: Google's definitive position

The choice between hyphens and underscores is not a style preference — it has a concrete, confirmed effect on how Google indexes your pages. Google's John Mueller has stated explicitly and on multiple occasions that hyphens are treated as word separators while underscores act as word joiners. In practice this means the slug word-count-tool is indexed as three separate words — «word», «count», and «tool» — and can match any of them individually. The slug word_count_tool is indexed as a single concatenated token, «wordcounttool», and will only match a search for that exact combined string.

The consequence for SEO is direct: hyphenated slugs rank for every keyword in the path segment, while underscored ones effectively hide those words from the search index unless the searcher types the joined form. This is the definitive reason every major CMS defaults to hyphens: WordPress, Drupal, Ghost, Shopify, Hugo, and Jekyll all generate hyphenated slugs from post titles unless you override the setting. Use underscores only in contexts that explicitly require them, such as programming identifiers, database column names, or internal API parameters that will never appear in a crawlable URL.

Beyond the hyphen-vs-underscore question, Google's broader URL guidance is to keep slugs short, descriptive, and stable. Avoid auto-generated numeric IDs like /p?id=12345 where possible — a human-readable slug helps Googlebot understand the page topic before it even reads the content. And once a page is published and indexed, changing the slug should be a last resort: even a correct 301 redirect passes only about 90–99% of link equity to the new URL, and any external links pointing to the old address take weeks or months to update in the index.

Internationalized slugs and transliteration strategies

Non-ASCII characters in URLs are technically legal under the Internationalized Resource Identifier (IRI) standard, and modern browsers like Chrome and Firefox will display the decoded Unicode form in the address bar — so a slug like /café-paris is rendered legibly rather than as /%C3%A9. However, the underlying HTTP request still transmits the percent-encoded form, and older tools, link-shorteners, and email clients sometimes mangle the encoded characters. For domains specifically, non-ASCII hostnames are handled by Punycode encoding (e.g. münchen.de → xn--mnchen-3ya.de), a separate system from path encoding.

Most CMS platforms and slug libraries default to transliteration: mapping each accented or non-Latin character to its closest ASCII equivalent before generating the slug. This produces universally safe URLs — niño-pinata becomes nino-pinata — at the cost of losing the original orthography. For Arabic, Hebrew, and CJK (Chinese, Japanese, Korean) scripts, where there is no meaningful one-to-one Latin mapping, transliteration is not practical. The common approaches are to use romanized transliteration systems (Pinyin for Mandarin, Hepburn for Japanese, ALA-LC for Arabic), to include both a localized and an English slug, or to allow the full Unicode slug and rely on the server and CDN to handle it correctly.

Shopify, WordPress (with the right locale plugin), and Contentful all support Unicode slugs natively and let the browser decode them for display. The technical requirements are that the server does not double-encode incoming paths, that the Accept-Language and canonical tags are set consistently, and that any redirect logic compares decoded URLs so that /caf%C3%A9 and /café are not treated as two different pages. For most Latin-script content, ASCII transliteration remains the simpler, safer default.

Slug collisions and how CMSs resolve duplicate titles

When two pages share the same title — or titles that produce the same slug after processing — a slug collision occurs. The universal resolution is sequential suffixing: the first post gets my-post, the second gets my-post-2, the third my-post-3, and so on. WordPress has done this since version 2.0; Django's AutoSlugField (via django-autoslug), Laravel's Str::slug with a uniqueness check, and Rails' FriendlyId gem all implement the same pattern. It prevents server errors but produces slugs that carry a number with no semantic meaning.

An alternative is to append a short hash or UUID fragment — my-post-a3f2 — which avoids the predictable incrementing pattern and makes the slug unique without implying any ordering. Some platforms incorporate a date prefix into the URL structure (/2024/06/my-post/) to sidestep collisions entirely, since the same title published in different months lives at a different path. Date-prefixed URLs work well for news and journalism sites but create long URLs and make evergreen content appear dated in search results.

For long-running sites with thousands of articles the collision strategy chosen early becomes expensive to change later. If slugs are already indexed and linked, switching from numeric suffixes to hashes — or from flat to date-prefixed URLs — requires 301 redirects for every changed address, a crawl lag of weeks while Googlebot processes them, and updated internal links throughout the content. The practical advice is to decide on a collision strategy before launch, make it part of your CMS configuration, and treat published slugs as permanent identifiers. Renaming them for aesthetics is rarely worth the SEO disruption.