kebab-case Converter Hyphenate Slugs and CSS Class Names

Kebab-case is the boring, useful way to name things: lowercase words joined by hyphens. If you need a slug, a CSS class, or a clean identifier that won’t fight your build tools, give our free text case tool a spin and stop hand-editing strings one dash at a time.

What kebab-case actually is

Kebab-case means each word is lowercase and separated with a hyphen, like user-profile or api-rate-limit. It reads well in URLs and class names because the separators are visible, but not noisy.

The format is simple on purpose. That simplicity matters when a string has to survive routing rules, CSS selectors, file names, build steps, or copy-paste into someone else’s config.

Compared with camelCase, kebab-case is easier to scan in long labels. Compared with snake_case, it tends to fit better with web slugs and CSS naming conventions. It also avoids spaces, which break more things than they help.

Why developers keep using it

The most common use case is front-end work. CSS class names like card-header, nav-item-active, and button--danger are readable and predictable, and they play nicely with selectors and markup conventions.

It also shows up in URLs. A route like /blog/how-to-reset-a-password is easier to read than /blog/HowToResetAPassword or /blog/how_to_reset_a_password, and it avoids the ambiguity that comes with capitalization in shared links.

In content workflows, kebab-case is often the final normalisation step before publishing. A title becomes a slug, a slug becomes a path segment, and that path segment ends up in analytics, caches, browser history, and probably someone’s bookmark bar.

If you want the bigger picture on slug formatting, our guide on converting URL slugs back to readable text is a good companion read.

When to use kebab-case instead of other text cases

Use kebab-case when the string is meant to be public-facing or shared between systems. That includes URLs, HTML class names, design tokens, file names, and labels that need to stay readable across editors and terminals.

Use something else when the target system expects it. JavaScript variables usually want camelCase, classes in many languages often want PascalCase, and constants still lean toward SCREAMING_SNAKE_CASE.

A quick rule of thumb:

• URLs and slugs: kebab-case
• CSS classes: kebab-case
• JS variables: camelCase
• Types and components: PascalCase
• Constants: SCREAMING_SNAKE_CASE

If you are sorting through all the common formats, our text case guide covers the tradeoffs without the usual naming-war drama.

How a kebab-case converter usually transforms text

A good converter does more than replace spaces with hyphens. It typically lowercases the text, removes or normalises punctuation, and collapses repeated separators so you do not end up with ugly chains like -- or ---.

For example, API Rate Limit becomes api-rate-limit. Version 2.0 Release Notes might become version-2-0-release-notes, depending on how the tool handles punctuation and decimals.

That detail matters. A sloppy conversion can create broken slugs, duplicate class names, or awkward file names that are hard to reverse later. A decent tool gives you output that is stable, consistent, and ready to paste.

When you are normalising a batch of text, the same logic applies line by line. Strip weird punctuation, lower-case everything, join tokens with hyphens, and keep the result deterministic so your build or CMS does not decide to be “helpful” in different ways on different days.

Common edge cases worth watching

Real-world text is rarely clean. You will get extra spaces, slashes, apostrophes, emoji, accents, and punctuation that does not belong in a slug or class name.

Here are the problems that show up most often:

• Multiple spaces: My New Page should become my-new-page, not my---new---page
• Punctuation: What's New? usually becomes whats-new
• Accents: Café Menu may become cafe-menu if the tool normalises diacritics
• Symbols: R&D / QA often turns into r-d-qa or rd-qa, depending on the cleanup rules
• Numbers: Part 2 should stay readable as part-2

For CSS, you usually want consistency more than linguistic perfection. For slugs, readability and search-friendly structure matter more, but the main goal is still the same: one input, one predictable output.

If the source text is messy enough, clean it first and convert it second. A text cleanup pass can remove invisible characters, smart quotes, and odd whitespace before the hyphenation step does its work.

Use it in scripts, templates, and content pipelines

Manual conversion is fine for a single title. It becomes annoying fast when you are generating dozens of identifiers from a CMS export, a markdown file, or a CSV column.

In code, the same idea is easy to implement, but a browser tool is often faster when you just need to check a result. You can paste a title, inspect the output, and move on without wiring up a helper function for one-off cleanup.

Input:  Launch Checklist for Q4 2025
Output: launch-checklist-for-q4-2025

Input:  Read Me / Setup Guide
Output: read-me-setup-guide

That kind of transformation shows up in static site generators, design systems, docs pipelines, and release tooling. It is especially useful when you need identifiers that are safe to store in git, display in a CMS, and reuse in front-end code without translation errors.

Real-World Example

Say you are turning article titles into slugs for a docs site. You want the output to be lower-case, hyphenated, and safe for URLs.

Input titles:
1. Build Your First API Client
2. What's New in v2.1?
3. CSS: Grid vs Flexbox
4.   Clean   Text   Fast   

Converted slugs:
1. build-your-first-api-client
2. whats-new-in-v2-1
3. css-grid-vs-flexbox
4. clean-text-fast

That is the shape you want: no spaces, no doubled separators, no awkward casing. Once a slug is generated, it can be dropped into a route, a filename, or a class name without more cleanup.

If you are building a batch workflow, feed a list into the tool, verify the output, and keep the naming rules consistent across your stack. That is much cheaper than fixing broken links after a deploy.

Frequently Asked Questions

What is kebab-case used for?

Kebab-case is used for slugs, CSS class names, filenames, and other identifiers that need to be readable and machine-friendly. It is especially common on the web because hyphens work well in URLs and are easy to scan.

Is kebab-case the same as a slug?

Not exactly, but they overlap a lot. A slug is usually a kebab-cased string made for a URL path, while kebab-case is the broader naming style of lowercase words joined by hyphens.

Should CSS classes be kebab-case?

Usually, yes. Kebab-case class names are readable, consistent, and easy to target in HTML and stylesheets. They also avoid the casing confusion that can happen with camelCase in markup.

How do I convert text to kebab-case quickly?

Use a converter that lowercases the text, replaces separators with hyphens, and removes punctuation you do not need. If you want to do it in the browser without building a script, use this text case tool and paste your text in.

The Bottom Line

Kebab-case is the quiet workhorse of web naming. It keeps slugs readable, class names consistent, and identifiers less annoying to debug later.

If you are cleaning up titles, refactoring CSS, or turning raw labels into URL-safe strings, it is worth using a tool instead of doing the dash math by hand. Start with our text case converter, check the output, and keep your naming rules boring in the best possible way.

That is usually the right trade: less manual cleanup, fewer naming mistakes, and one less tiny thing to fix when the rest of the build is already on fire.