From Title to Live URL: A 4-Step Slug Workflow Using One Tool
Turning a raw post title into a safe, ready-to-publish page usually touches more than just the URL slug. Here's a practical four-step workflow — slug, reserved-word check, file name, naming case — that covers the full set of small decisions you make right before hitting publish, all from the same starting title.
Quick answerStart with the Single mode: paste your working title, pick a hyphen separator, and optionally strip stopwords or numbers. This gives you the core slug every later step in this workflow builds on.
Everything downstream — the reserved-word check, the file name, the naming-case variants — depends on the slug you settle on first, so it's worth getting this step right before moving on rather than revisiting it later. A working title rarely looks like a slug: it has capital letters, punctuation, maybe a subtitle in parentheses, and sometimes an accented name or place.
Practical scenario: say the working title is "Understanding Café Culture: A Traveler's Guide to Lisbon (2026 Edition)." Running that through Single mode with stopwords removed and the parenthetical trimmed away lands on something like understanding-cafe-culture-travelers-guide-lisbon — accents resolved, punctuation gone, and still readable as a topic at a glance.
Rule of thumb: treat the slug from this step as provisional until it clears step 2 — don't wire it into a CMS field or a file path yet.
Step 2 — Check it against reserved words
Quick answerBefore committing to the slug from step 1, run it through the reserved-word checker. A candidate slug that happens to match a common system or CMS route name — like admin, api, login, or category — can silently conflict with an existing route once the page goes live.
This step matters most for short, generic titles rather than long descriptive ones — a post literally titled "Feed" or "Login Help" is far more likely to produce a slug that collides with something your framework already reserves. It only takes a few seconds to check, and it's much cheaper to catch here than after the page is live and quietly fighting a system route for the same path.
Worked example (illustrative only): a support-docs page titled simply "Feed" would naturally slug to feed. Checking that candidate against the reserved-word list flags it as a likely conflict with a syndication or activity-feed route, prompting a small rename to something like feed-troubleshooting before publishing.
Step 3 — Clean the matching asset file name
Quick answerOnce the slug is confirmed, run the featured image (or any other asset tied to the post) through the file name cleaner. It strips spaces and symbols while preserving the file extension, so the asset's own URL path stays as tidy as the post slug it sits alongside.
It's easy to focus entirely on the page slug and forget that an uploaded image often keeps whatever messy name it arrived with — a phone's default photo name, a stock-photo download, or a screenshot labeled with a timestamp. That name frequently becomes part of the asset's own public URL, so a clean post slug next to an asset path like IMG_20260719_FINAL(2).jpg still looks inconsistent to anyone inspecting the page's URLs.
Practical scenario: for the Lisbon travel post from step 1, a photo saved locally as "Lisbon Sunset Photo (Best One) FINAL.jpg" gets cleaned up to something like lisbon-sunset-photo-best-one-final.jpg — same extension, no spaces or parentheses, consistent with the rest of the page's URL structure.
Step 4 — Derive the naming-case variants you'll actually need
Quick answerIf the same title needs to become a front-matter key, a JSON field, or a database column alongside its URL slug, switch to the Naming case tab once instead of retyping and reformatting the title by hand for each destination — it shows kebab-case, snake_case, camelCase, PascalCase, and a few others side by side.
Not every publishing setup needs this step — a simple blog where the CMS handles the slug-to-database mapping automatically can usually skip it. But static site generators, headless CMS setups, and custom publishing scripts often expect the same identifier in more than one casing: kebab-case for the URL, snake_case for a front-matter or database field, maybe camelCase if the post metadata gets pulled into a JavaScript object somewhere in the build.
Same slug source, different destinations
Convention
Typical destination
Example
kebab-case
Live URL slug
understanding-cafe-culture
snake_case
Front-matter / database field
understanding_cafe_culture
camelCase
JS metadata object key
understandingCafeCulture
PascalCase
Component or template file name
UnderstandingCafeCulture
Doing this last, after the slug has already cleared the reserved-word check, avoids the annoyance of generating a full set of naming variants for a slug you end up renaming a step later.
Run the whole workflow from one title: generate the slug, check it against reserved words, clean the matching file name, and derive every naming-case variant — all free, all in your browser.
What order should I run slug generation, reserved-word checking, and file naming in?
Generate the slug from the title first, since every later step depends on it. Then check that slug against reserved system words before you commit to it. Only after the slug is confirmed safe should you clean the matching image or asset file name and derive any variable-name conventions you need — reworking a slug after the file names are already set means redoing those steps too.
Does the reserved-word checker know about my specific CMS or framework's routes?
No — it checks a candidate slug against a list of common, widely reused system and CMS route names (things like admin, api, login, category, tag). It is a useful first pass, not a guarantee for every possible framework, so it's still worth a quick manual check against your own app's specific route list for anything unusual.
Why clean up an image file name at the same time as the slug?
A blog post's featured image is often uploaded with the same descriptive name as the title (for example, straight from a camera roll or stock-photo download), and that same name usually ends up in the image's URL path. Cleaning it alongside the post slug — stripping spaces and symbols while keeping the file extension — keeps the whole page's URLs, not just the slug, consistent and readable.
Do I need camelCase or snake_case if I'm only publishing a blog post, not writing code?
Often yes, indirectly. Many blogging setups store a post's slug as a database column or a front-matter key (for static site generators), and some also expose it as a JSON field for an API or search index. If any part of your publishing pipeline touches code, having the snake_case or camelCase version ready alongside the kebab-case slug avoids retyping it by hand later.
Should the username or handle for a guest author be generated the same way as a slug?
It's a related but separate step, not the same one. A slug describes a page's content; a username or handle identifies a person and usually needs to stay short, memorable, and consistent across platforms. Running both through the same session is convenient because the underlying cleanup rules (lowercasing, stripping accents and spaces) overlap, but treat the two outputs independently before finalizing either.
A note on this guide: the worked examples above use illustrative, hypothetical titles and file names to demonstrate how this workflow applies — they are not claims about any specific real website's traffic, rankings, or publishing process. This content is for general informational purposes and isn't a substitute for your CMS or framework's own documentation.