URL Slug Generator

What This Tool Does

A URL slug is the human-readable tail of a URL — the my-first-post in https://example.com/blog/my-first-post. Slugs are derived from titles or headlines and exist to make URLs scannable, shareable, and search-engine friendly. The slug generator on this page performs the full canonical transformation pipeline: lowercase the input, strip diacritics through Unicode normalization, remove or replace every character that is not a lowercase letter, digit, or the configured separator, collapse consecutive separators into one, and trim leading or trailing separators from the result.

The tool runs entirely in your browser. Whatever you paste into the input never leaves the device — there is no upload, no server round-trip, and no logging of your text. That matters if you are sluggifying internal product names, unreleased article titles, or anything else where pre-publication leakage would be a problem.

Three configurable behaviors give you control over the output: a separator chip lets you swap hyphens for underscores or dots (relevant for snake_case database column slugs or dotted bundle identifiers); a maximum length input enforces a hard ceiling truncated at the nearest separator so words are not cut in half; and a "remove stop words" checkbox strips a, the, of, and, and roughly seventy similar high-frequency function words from the slug. Stop-word removal is opt-in because it can destroy meaning in short titles, as discussed in the edge-cases section below.

How to Use It

Paste Titles into the Input Pane

The textarea on the left accepts one title per line — enter as many as you need and the tool slugifies all of them in a single pass. The right pane updates live as you type, debounced by 150 ms so it stays responsive on long inputs. Use the Try Example button to pre-load a representative set of titles that exercises every code path in the slugifier: title-case capitalization, mixed punctuation, parentheses, exclamation marks, accented characters, and a longer multi-word headline. The Clear button empties both panes and refocuses the input cursor.

Choose a Separator

The three chips above the input set the separator inserted between words. Hyphen is the default and the SEO-recommended choice for public URLs because search engines treat hyphens as word boundaries when tokenizing the URL string. Underscore is appropriate for slugs used as database column values or filenames in systems where hyphens collide with command-line argument parsing. Dot is useful for bundle identifiers (com.acme.product.feature) and for some test-fixture naming conventions, though it is rarely a good choice for public URLs because trailing dots can confuse some routing layers.

Set Length and Stop-Word Options

The Max Length field caps the output at the specified number of characters. Set it to zero to disable truncation entirely. When truncation kicks in, the algorithm first cuts at the literal character index, then walks back to the nearest separator if doing so keeps at least half the requested length — this avoids producing slugs that end in the middle of a word, which look broken to humans and hurt scan-ability in search results. Toggle Remove stop words to drop high-frequency function words from the slug. The stop-word list covers the standard English set; if you need locale-specific stop-word removal (Spanish, French, German), do it as a pre-processing step before pasting into this tool.

Copy or Download the Output

The Copy button copies all slugs (one per line) to the clipboard via the browser Clipboard API. Download writes them to a slugs.txt file so you can pipe the result into a migration script or paste it into a spreadsheet column. The status bar below the panes reports the count of slugs produced and confirms that processing completed without truncation issues.

Common Use Cases

Blog Post and Article URLs

Blog platforms convert post titles to slugs automatically: WordPress, Ghost, Hugo, Jekyll, and 11ty all ship slugify functions in their core. When you migrate content between platforms — say, exporting from WordPress and importing to Hugo — the slug strategies frequently differ subtly (WordPress retains some Unicode by default; Hugo with Goldmark strips more aggressively), and the result is broken inbound links. Generating a consistent slug set in advance lets you set up server-side redirects from the old slugs to the new ones in one batch.

SEO-Friendly Product Pages

For e-commerce, the slug is part of the page's primary on-page SEO signal alongside the H1 and meta description. A product URL like /products/blue-leather-wallet outperforms /products/sku-83471 in click-through rate from organic search because the slug itself acts as a snippet preview. The 50-80 character target window applies; longer slugs sometimes get truncated in mobile SERPs with an ellipsis.

GitHub Repository Names

GitHub repo names follow a slug-like convention but with stricter rules: only ASCII letters, digits, hyphens, underscores, and dots; max length 100 characters; cannot start or end with special characters; cannot contain consecutive special characters. The slug generator's hyphen mode produces compliant repo names out of the box. Repository slugs feed into clone URLs, package registry coordinates (for example, the JavaScript scoped package name in package.json), and CI pipeline references — getting it wrong once propagates everywhere.

S3 Bucket Naming and Object Keys

AWS S3 bucket names follow DNS-style rules: lowercase only, 3-63 characters, no underscores, no consecutive dots, must start and end with a letter or digit. Object keys are looser but conventional slugs improve human navigation in the S3 console. Generating a slug specifically for bucket creation typically requires the hyphen separator and a max-length cap of 63.

JIRA, Stripe, and OpenAPI Identifiers

JIRA project keys are uppercase alphanumeric (no hyphens), so a slug is a starting point that requires manual capitalization. Stripe customer and product IDs use the prefix-plus-random-hash pattern (cus_8z7Fk2), but the human-readable description fields often store a slug-style identifier for cross-referencing with internal systems. OpenAPI operationId values must be valid identifiers in every target language the spec generates client SDKs for — kebab-case slugs typically get converted to camelCase during code generation, which is why the slug-as-source-of-truth pattern is durable across languages.

Edge Cases and Limitations

The simple slugifier above handles English-language titles cleanly. Several categories of input require either deliberate configuration choices or external pre-processing.

Non-Latin scripts. Russian, Greek, Arabic, Hebrew, Chinese, Japanese, Korean, Thai, and other non-Latin scripts present a fundamental choice: transliterate to Latin ASCII (Москва becomes moskva), preserve the original script via percent-encoding in the URL (%D0%9C%D0%BE%D1%81%D0%BA%D0%B2%D0%B0), or use Internationalized Domain Names (IDN) for full Unicode URLs. This tool currently strips non-Latin characters entirely — for transliteration coverage, use python-slugify with the unidecode backend on a server, or the transliteration npm package in the browser.

Emoji and pictographic characters. Emoji are valid Unicode but produce visually broken slugs when percent-encoded. The tool strips them. If you need to preserve emoji semantics (rare, but it happens in some social-media content systems), substitute the emoji with its CLDR short name before slugifying: 🚀 becomes rocket.

Reserved URL characters. RFC 3986 reserves ?, &, #, /, :, @, %, +, and several others — these must never appear unencoded in a slug because they have grammatical meaning in URLs (query string delimiter, fragment marker, path separator, etc.). The slugifier strips all of them. If your input string contains literal hash marks or ampersands and you need them preserved for some reason, percent-encode the slug after generation rather than trying to preserve them in raw form.

Case-insensitive filesystems. macOS HFS+ and APFS default to case-insensitive (case-preserving) behavior; Windows NTFS does the same by default. If your slug is also a folder or file path on disk, FOO and foo map to the same directory on those filesystems but to different directories on Linux ext4 — a classic source of "works on my machine" bugs. Always lowercase slugs that touch disk.

Maximum length constraints. Practical limits cluster around three numbers: 50 (Google's recommendation for SEO-readable URLs in mobile SERPs), 63 (DNS label limit, applies to S3 buckets and subdomains), and 255 (the most common VARCHAR column ceiling in legacy SQL schemas). Pick the lowest of the three for your use case and configure the max-length input accordingly.

Slug uniqueness and collisions. Two articles titled Annual Report generate identical slugs and will collide on any UNIQUE constraint. Standard mitigations: append a numeric suffix on collision (annual-report, annual-report-2), append a short hash (annual-report-a3f), or include a date stub in the slug (2025-annual-report). The right answer depends on whether the slug needs to be guessable or whether opaque suffixes are acceptable.

Stop-word removal trade-offs. Stripping the, of, and and from The Lord of the Rings produces lord-rings — readable but slightly off. From To Be or Not to Be, stop-word removal produces the unhelpful slug not. The pragmatic rule: only strip stop words from titles of seven or more content words, and prefer to keep the slug intact for short, well-known titles.

Numeric prefix gotchas. Leading digits are legal in URL slugs, but a slug like 2025 alone is too ambiguous to be useful as a permalink — append a content word: 2025-tax-brackets, not 2025.

Behind the Scenes: Unicode Normalization and Algorithm Details

The Four Unicode Normalization Forms

Unicode defines four normalization forms that determine how composite characters are encoded internally: NFC (canonical composition), NFD (canonical decomposition), NFKC (compatibility composition), and NFKD (compatibility decomposition). The distinction matters for slug generation because accented characters can be encoded two ways: as a single composite code point (U+00E9 for é) or as a base letter followed by a combining mark (U+0065 e plus U+0301 combining acute accent). Both render identically, but byte-level operations see them differently.

The Standard Diacritic-Stripping Idiom

The canonical JavaScript pattern for stripping diacritics is two operations: first normalize the string to NFD (which splits every composite into base letter plus combining marks), then run a regex over the result that removes everything in the Unicode combining-marks block:

str.normalize('NFD').replace(/[̀-ͯ]/g, '')

This converts café (NFC: c a f é) first to NFD (c a f e combining-acute), then strips the combining acute, leaving cafe. The regex range ̀-ͯ covers the full Combining Diacritical Marks Unicode block. This idiom is short, fast (the V8 NFD implementation is highly optimized), and handles every accent found in European Latin-script languages including Polish (ł requires special handling), Czech (č, ř), and Vietnamese (which stacks up to three combining marks on a single base letter).

Compatibility Decomposition for Ligatures

NFKD goes a step further than NFD: it also decomposes compatibility characters, where two distinct Unicode code points represent the same letter for visual reasons. The classic example is the ligature fi (U+FB01), a single code point that renders as the joined letters "fi". NFKD decomposes this into separate f and i code points, after which the slug generator handles them like any other ASCII letters. Use NFKD when your input may include ligatures from typographic content (PDF extracts, OCR output, Word documents); NFD is sufficient for ordinary keyboard input.

Library Comparison

The two dominant JavaScript libraries for slug generation are slugify (Trent Oswald, around 2 million weekly npm downloads) and slug (Daniel Bugl, around 1.5 million weekly downloads). slugify accepts a locale option that swaps in language-specific transliteration tables (Turkish ı to i rather than to nothing, German ß to ss, and so on). slug ships with broader transliteration coverage by default but uses a larger character map and is correspondingly slightly slower. In Python, python-slugify backed by the unidecode package is the de facto standard and supports transliteration for essentially every writing system. Django's built-in slugify is intentionally simple: NFD normalization, strip combining marks, lowercase, replace non-alphanumeric with hyphens, collapse and trim — the same five-step pipeline this tool uses.

How Wikipedia Generates URL Slugs

Wikipedia takes a different approach: it preserves the original article title essentially verbatim in the URL, percent-encoding any characters that are not URL-safe. The article on coffee in French Wikipedia lives at fr.wikipedia.org/wiki/Caf%C3%A9 — that's Café with é percent-encoded as UTF-8 bytes C3 A9. This preserves the readable title in browser address bars on modern browsers (which display the decoded form) while keeping the underlying URL ASCII-safe. The approach trades clean slugs for round-trip fidelity to the source title.

Comparison: This Tool vs. slugify (npm) vs. python-slugify vs. Django vs. Wikipedia

Each slugifier listed here makes different trade-offs between coverage, speed, and integration surface. The summary below is also rendered visually in the SVG chart in the worked-example section above.

This Tool

Browser-based, zero dependencies, instant feedback on copy-pasted input. Handles the full Latin-script diacritic range via NFD normalization plus a built-in transliteration map for special Latin extensions (ł, ß, æ, ø). Non-Latin scripts are stripped rather than transliterated. Best fit for one-off slugification and pre-publication content audits where you want to inspect the result before committing it.

slugify (npm)

Lightweight JavaScript library for build-time or runtime slug generation. Locale-aware transliteration maps for German, Turkish, Vietnamese, and others. No built-in stop-word removal — you supply the regex if needed. Best fit for content-management systems and static site generators that produce slugs as part of the build pipeline.

python-slugify

The most comprehensive option among server-side libraries. Transliterates via unidecode (covers Cyrillic, Greek, CJK, Arabic, Hebrew, Thai, and dozens of other scripts), supports custom replacement tables, stop-word removal, max-length truncation with word-boundary respect, and configurable separator. Best fit for production backend pipelines and content migration scripts.

Django slugify

Intentionally minimal: NFD-strip, lowercase, replace non-alphanumeric with hyphens, collapse, trim. Does not transliterate (Cyrillic and CJK are stripped entirely). Pure-stdlib, ships with the framework, zero dependencies beyond Python. Best fit for Django apps where the default behavior is good enough and adding a dependency is undesirable.

Wikipedia

Not a slugifier in the traditional sense — Wikipedia preserves article titles in URLs via percent-encoding rather than transliteration. The result is an opaque ASCII URL that decodes to the readable title in modern browsers. Best fit for systems where round-trip fidelity to the source title matters more than human readability of the URL itself.

Related Tools

After generating slugs, a few adjacent text-transformation tools cover the rest of the pre-publication pipeline. The Case Converter applies title case, sentence case, camelCase, or PascalCase to text — useful when you need a slug in one casing convention and the human-readable title in another. The Word Counter reports word and character counts, helpful for confirming that a slug stays within the 50-80 character SEO target without manual measurement.

For deeper SEO work, the Meta Tag Generator builds the full set of meta and Open Graph tags for a page, and the SERP Preview shows how the slug and title will appear in a Google search result snippet at desktop and mobile widths. The UTM Builder appends campaign tracking parameters to a slugified URL without breaking the underlying canonical structure.