Text & everyday tools · Text Toolkit
URL slug conventions: hyphens, lowercase and what RFC 3986 allows
· Background
url-slugs content-management text-tools
Explains where slugs came from, which characters RFC 3986 leaves unreserved, why hyphens won over underscores and why lowercase matters, and how these rules shape what a slug generator produces.
The URL nobody can read aloud — spaces as %20, capitals that break links, and why slugs exist
A page path such as `New Product Launch 2026` is awkward when copied directly into a URL. Spaces need another representation, mixed capitals invite inconsistent typing, and punctuation can make the address harder to scan. A slug gives the page a compact path segment that people can recognize beside the site name.
The repository does not document when slugs originated or prove a universal reason for their adoption, so the useful question here is operational. A site owner needs one repeatable transformation from an editable headline to a publishable path. ToolAcre supplies that transformation without pretending the result preserves every typographic detail.
The URL nobody can read aloud, without assigning an undocumented origin story to slugs
ToolAcre does not implement a general RFC 3986 parser or validator. Its `slugify` function normalizes the input, removes combining marks, lowercases the result, replaces runs of characters other than letters and numbers with a chosen separator, and trims separators from both ends. Those source-backed rules define this generator more precisely than a broad standards label.
That distinction matters when setting a content-management policy. A character may be usable somewhere in a URL while still being removed by this particular slug transform. Treat the generated path as an editorial convention, not as a complete inventory of every legal URL character, reserved delimiter, or percent-encoded representation accepted by other systems.
What this slug implementation accepts, rather than a complete RFC 3986 interpretation
Hyphens are the default separator in `slugify`, and consecutive punctuation or whitespace collapses into that same separator run. The headline `Quarterly report: costs & margins` therefore becomes `quarterly-report-costs-margins`, rather than exposing the colon, ampersand, or spaces in the path. The output remains visibly divided into words.
The source does not establish that hyphens defeated underscores through a particular search-engine decision, so that history should not be presented as fact here. The defensible guidance is simpler: select one separator for the site, apply it consistently, and avoid manually mixing forms that differ only because separate editors followed separate habits.
Hyphens as this generator's separator, without claiming an unsupported search-engine history
Lowercase is applied before the slug is returned. That makes `About Our Team`, `ABOUT OUR TEAM`, and `about our team` converge on `about-our-team` under this transform. A predictable lowercase path is easier to reproduce from a title and avoids creating editorial variants whose only visible difference is capitalization.
Whether two differently cased paths resolve to the same resource depends on the surrounding host, router, deployment, and redirect rules; this text utility cannot determine that behavior. The practical CMS rule is to publish one lowercase canonical path and make any redirect policy explicit elsewhere, rather than relying on an unverified assumption about case handling.
Length, stop words and stability — practical guidance on what to keep in a slug and what to drop
Shorter is not automatically better. Keep the words that let an editor distinguish the page from nearby content, especially a product, task, or subject name. Drop wording only when the remaining path is still specific. A slug that is brief but ambiguous creates maintenance work when several articles later compete for the same candidate path.
ToolAcre supports a `maxLength` option in its underlying function, but the case-converter configuration describes a whole-text slug action rather than a visible length control. More importantly, truncation is not an editorial strategy. Decide which words matter before publishing, then keep the chosen slug stable when cosmetic headline wording changes after launch.
Worked example — turning three real headlines into slugs and checking each against the rules
Consider three headlines. `Cafes, Costs & Margins` becomes `cafes-costs-margins`; `Launch Notes: Version 2` becomes `launch-notes-version-2`; and `A Guide to Better Page Names` becomes `a-guide-to-better-page-names`. Each result is lowercase, uses hyphens between retained word runs, and removes punctuation that is not a letter or number.
The first example is deliberately plain ASCII, but the same source rule can fold a decomposed accent from a Latin letter to its base form. Review every result before assigning it to content: the function has no knowledge of brand spelling, preferred abbreviations, duplicate routes, or words an editorial team considers expendable.
What this does not cover — internationalised domain names and the choice to keep non-Latin scripts in a URL
Non-Latin letters are not universally discarded by this implementation. The regular expression retains letters and numbers across scripts, while the configuration states that slugs keep non-Latin scripts lowercased without transliteration. Claiming that the tool always converts a title to ASCII would therefore contradict both the source and the published tool limits.
This transform also does not configure internationalized domain names, choose a host name, or transliterate words between writing systems. Those are separate policy decisions. For a multilingual site, test the generated path in the actual CMS and routing stack, then decide whether retained script or a separately authored translation best serves that site.
Non-Latin letters are retained; transliteration and domain names are outside this transform
A useful slug policy can be concise: begin with the page title, lowercase it, join recognized word runs with hyphens, remove surrounding separators, preserve meaningful numbers, and review the result for clarity before publication. Record collision and redirect behavior in the CMS rules, because a text transform cannot inspect existing routes or protect inbound links.
The Text case converter applies the mechanical portion in one action. Paste a headline, choose the slug transform, and inspect the output before copying it into the page path. It folds supported accents, removes symbols, collapses separators, and produces lowercase text, leaving content meaning and long-term URL stability with the editor.