Slug Generator

A URL slug is the readable part of a web address that identifies one particular page. It is the last segment of the path, and it is usually the only part of a URL a person actually reads.

1https://example.com/blog/seo-friendly-url-guide2└─┬──┘   └────┬────┘ └─┬─┘ └──────────┬───────┘3  │           │        │              │4protocol    domain    path        the slug

The name comes from newspapers, where a “slug” was the short working title given to a story as it moved through production. It does the same job here: a compact, human label for a piece of content.

Everything else in the URL is fixed by your infrastructure. The domain is bought, the protocol is configured, the path structure is decided once. The slug is the one part written fresh for every page — which makes it the part worth thinking about.

The process is short enough to do in your head, and the generator above follows exactly these steps in this order.

1. Start from the page topic, not the headline. A headline can be clever; a slug should be plain. “Why Your Site Feels Slow (And What To Fix First)” is a good title and website-performance-checklist is a better slug.
2. Drop the punctuation. Colons, ampersands, question marks and quotation marks either break a URL or get encoded into noise.
3. Keep the words that carry meaning. Cut filler, keep anything that tells the reader what the page is.
4. Separate words with hyphens and lowercase the result.
5. Stop when it is clear. Extra words past the point of clarity only make the URL harder to read and share.
6. Read it back as if you had never seen the page. If you cannot tell what the page is about from the slug alone, it needs another word. If you can, it needs nothing.

If you are pasting titles out of a CMS, the generator handles the mess that comes with them — smart quotes, non-breaking spaces, stray HTML tags and percent-encoded characters are all cleaned up before the slug is built.

A readable slug earns its keep in several places at once, and only one of them is a search algorithm.

• Search results. The URL is displayed above or below the title in most results. A descriptive one confirms the page is what the title promised; a string of identifiers gives the reader nothing.
• Shared links. Pasted into a message, a document or a slide, a bare URL is often all the context the recipient gets.
• Link text. Plenty of links are created by pasting a URL rather than writing anchor text, so the slug becomes the description by default.
• Navigation and orientation. People read the address bar to work out where they are in a site, and edit it to move around.
• Your own maintenance. Server logs, analytics reports and redirect tables are all lists of paths. Readable ones make those legible.

As a ranking factor the URL is minor and search engines have said so. Treat the slug as a usability decision that happens to be visible to crawlers, rather than the other way round, and you will make the right call every time.

Each pair below differs in one specific way. The fault is named rather than left as a general feeling, because “make it descriptive” is not advice anyone can act on.

Both are legal in a URL and neither will break anything. The recommendation is still hyphens, for two independent reasons.

The first is how search engines read them. Google has stated for many years that it treats a hyphen as a word separator and an underscore as a word joiner, so best_seo_tools can be read as a single token where best-seo-tools is read as three words.

The second is more mundane and matters more often: links are usually underlined. An underscore sits exactly where the underline goes, so best_seo_tools renders as best seo tools with invisible gaps — and anyone retyping it from a screen guesses wrong.

1best-seo-tools     ✓  hyphens — read as three words, visible when underlined2best_seo_tools     ~  underscores — valid, but joined and hard to see3best%20seo%20tools ✗  encoded spaces — valid, unreadable everywhere

Underscores are not a mistake worth migrating an established site for. If your URLs already use them and they work, the cost of changing every path outweighs the benefit. Use hyphens for anything new.

Yes — and the reason is not style, it is that the path portion of a URL is case-sensitive on most servers.

Linux servers, which host the majority of the web, treat /About-Us and /about-us as two different paths. Usually one of them 404s. Occasionally both resolve, and then you have the same content at two URLs competing with each other and splitting whatever links each has earned — the case where a canonical tag is what names the version you want counted.

Windows servers are case-insensitive, which sounds like the safer option and is worse: the problem simply does not appear until the site moves. Lowercasing everything removes the entire class of issue on every platform, which is why it is on by default above.

Stop words are the small grammatical words — a, the, of, to, in, for. Removing them shortens a slug, and it is a genuine trade rather than a free win.

The case for removing them: they carry no topical meaning, so a shorter URL says the same thing. The case against: they carry grammatical meaning, and without them a slug can stop reading like language. how-to-build-a-website becomes how-build-website — three characters saved and a phrase lost.

Remove them when a slug is genuinely unwieldy. Keep them when losing them costs you a readable phrase, which is most of the time. That is why the option above is off by default.

The list this tool uses is deliberately narrow — articles, conjunctions, common prepositions and the verb “to be”. It never removes question words like how, what or why, because those are frequently the entire point of the page.

Stop-word removal is only applied to English text. Running an English list over another language removes words at random, so if you are working in another language, leave the option off.

There is no character limit that guarantees anything, and any specific number you have read was made up. Search engines have never published a slug length threshold.

What is true is more useful. Search results truncate long URLs visually, so anything past roughly sixty characters may not be seen. Long URLs are harder to scan, harder to read aloud and more likely to wrap awkwardly when pasted. And a long slug is usually long because it contains words that are not doing anything.

The practical target is the shortest slug that still makes the topic obvious — typically three to six words. Test it by covering the page title and reading only the slug: if you can tell what the page is, it is long enough.

The optional length limit in the tool exists for systems with a real column limit, not for SEO. When it truncates, it cuts on a whole word, because the-complete-guide-to-search-en reads as a bug rather than a shortening.

Yes. Internationalised Resource Identifiers are a standard, every current browser displays them correctly, and a path like /日本語のタイトル is perfectly valid.

The complication is what happens when the URL leaves the browser. Underneath, the address is still percent-encoded, so copying that path out of the address bar can produce something like /%E6%97%A5%E6%9C%AC%E8%AA%9E — which is what your reader pastes into an email, and what appears in your analytics.

The choice comes down to who is reading the link:

• Unicode when the audience reads that script and links are mostly clicked rather than copied. The URL is more meaningful to the people who matter.
• ASCII when links will be pasted into other tools, shared across languages, or handled by systems whose Unicode support you cannot verify. Transliteration keeps some of the meaning — Привет мир becomes privet-mir.

This tool romanises where an established transliteration exists — accented Latin letters, Greek and Cyrillic — and deliberately does not invent one for Chinese, Japanese, Arabic, Hebrew or the Indic scripts. Those have several competing romanisations, most of them context-dependent, so a character-by-character conversion would produce confident nonsense. In ASCII mode they are dropped, and the tool tells you so rather than silently returning a shorter slug.

Usually not. An established URL has accumulated inbound links, bookmarks, shares, search rankings and references in other people’s documents — none of which you control, and all of which point at the old path.

Change it when the slug is actively wrong: it describes content that no longer exists, contains a typo that undermines trust, or was auto-generated into something like post-4471. Do not change it because a better wording occurred to you.

When you do change one, do it properly:

1. Add a 301 permanent redirect from the old path to the new one, live at the same moment as the change. A 301tells crawlers the move is permanent, so the new URL inherits the old one’s standing.
2. Update internal links to point at the new URL directly. Redirects work, but a chain of them is slower and dilutes the signal.
3. Keep the redirect indefinitely. Old links keep arriving for years, and a redirect costs nothing to leave in place.
4. Watch your 404 log afterwards for paths you did not think to redirect, and regenerate your XML sitemap so it lists the new paths rather than the old ones.

The corollary is worth stating: get the slug right before publishing, when it costs nothing to change. That is what the generator above is for.

A summary you can apply without rereading the rest of this page.