✏️ Slug & Case Converter

Why Text Case Matters More Than You Think

Every developer has been there: you copy a database column name into a JavaScript variable, paste a URL slug into an HTML class attribute, or try to match an API field name to a config key — and nothing lines up. The issue isn't complexity; it's just inconsistent naming conventions across layers of a project. Understanding how to convert between naming styles, and doing it fast, is one of those unglamorous skills that genuinely saves hours across a career.

This guide covers every major casing format, explains exactly where each one belongs, and gives you a clear checklist for picking the right one on the first try.

The Seven Case Formats — What They Are and Where They Live

camelCase — starts lowercase, each subsequent word capitalised, no separators. This is the default in JavaScript for variable and function names (getUserById, fetchOrderData). JSON keys almost universally use camelCase too, which is why REST APIs built in Node.js tend to feel consistent without any extra effort.

PascalCase — same idea as camelCase but the first letter is also capitalised (UserController, ProductCard). If you're in React, every component filename and component function name should be PascalCase — the JSX parser actually relies on this to distinguish custom components from native HTML tags. In C# and Java, class names follow PascalCase by convention.

snake_case — all lowercase, words joined by underscores (user_id, created_at). This is the lingua franca of Python and Ruby. PostgreSQL column names are stored in lowercase, and most ORM models in Django or SQLAlchemy use snake_case for field definitions. If you're working across a Python backend and a JavaScript frontend, you will almost certainly need to convert between snake_case (API response) and camelCase (JS object property) at some point — usually via a middleware or a single serialisation mapping step.

SCREAMING_SNAKE_CASE — like snake_case but entirely uppercase (MAX_RETRIES, DATABASE_URL). Reserved for constants and environment variables. In Python it signals module-level constants; in .env files and CI/CD configs, every variable is written this way. If you see a lowercase environment variable in a Dockerfile, that's a red flag.

kebab-case — all lowercase, words joined by hyphens (button-primary, modal-overlay). This is CSS's native convention. BEM naming (card__title--active) is an extension of it. HTML attributes like data-user-id and custom element names (my-component in Web Components) follow kebab-case. JavaScript technically can't use hyphens in identifiers, so you'll never see kebab-case in JS source code — but you'll see it everywhere in your stylesheets and HTML.

URL Slug — similar to kebab-case but with additional sanitisation: accent characters normalised, special characters stripped, multiple hyphens collapsed. A slug like how-to-center-a-div is readable, bookmark-friendly, and SEO-meaningful. CMS platforms like WordPress, Ghost, and Strapi generate these automatically, but when you're naming routes manually in Express, FastAPI, or Next.js, you need to produce them correctly.

dot.case — words joined by dots (logger.level, app.database.host). Common in configuration files, especially Java property files and some logging frameworks. Rarely used for code identifiers but shows up constantly in config namespacing.

The Tokenisation Step Nobody Explains

The tricky part of case conversion isn't applying a format — it's splitting the input correctly before you do anything. Consider the string XMLParser. A naive uppercase-split approach gives you x-m-l-parser, which is wrong. The correct result is xml-parser because "XML" is an acronym-as-word.

A robust converter handles this in two passes. First, split on transitions from a run of uppercase letters followed by a capitalised word: XMLParser → XML Parser. Second, split on lowercase-to-uppercase transitions: camelCase → camel Case. Then normalise all separators (hyphens, underscores, dots, spaces) into a single space, strip non-alphanumeric characters, and lowercase the whole thing. What you're left with is an array of clean lowercase tokens — the universal intermediate representation that you can then reassemble into any target format.

This two-pass approach means the converter above handles all of these inputs correctly: hello world, helloWorld, HelloWorld, hello-world, hello_world, HELLO_WORLD, XMLParser, parseHTTPResponse, and even mixed junk like some--messy input!! .

Practical Checklist: Picking the Right Case

• JavaScript variable or function? → camelCase
• JavaScript class or React component? → PascalCase
• CSS class or data attribute? → kebab-case
• Python variable, function, or Django model field? → snake_case
• Python class? → PascalCase
• Environment variable or constant? → SCREAMING_SNAKE_CASE
• URL path segment or blog post URL? → URL slug (kebab, sanitised)
• Config file namespace key? → dot.case
• Database column name (PostgreSQL/MySQL)? → snake_case
• REST API JSON field? → camelCase (if Node) or snake_case (if Python/Rails)
• GraphQL field name? → camelCase (spec convention)
• PHP variable? → camelCase or snake_case (depends on framework; Laravel uses snake_case for DB, camelCase for methods)

Where Inconsistency Actually Hurts

When a frontend team uses camelCase for everything and the backend team uses snake_case, the bridge between them becomes a tedious manual translation table. Some teams solve this with libraries like humps (JS) that automatically convert response keys. Others configure their serialiser (Django REST Framework, for example) has a CamelCaseJSONParser package) to handle the translation. But neither approach eliminates the need to actually understand the conversion — debugging a missing field is much faster when you immediately recognise that first_name from Python and firstName in React are the same data.

File naming is another pain point. Next.js requires page files to use specific conventions; accidentally naming a route component userDashboard.jsx instead of UserDashboard.jsx won't cause an immediate error but will break the component import pattern. The same goes for CSS Modules — most setups expect the module file in kebab-case, then import it into camelCase handles inside JS.

A Few Edge Cases Worth Knowing

Numbers in identifiers behave inconsistently across converters. h2o might tokenise as one word or split into h, 2, o depending on the implementation. The converter here keeps alphanumeric runs together, so h2o stays h2o in snake_case and becomes H2o in PascalCase — which matches Python's convention for variable names containing numerals.

Accented characters — café, résumé, naïve — need NFD Unicode normalisation followed by stripping combining characters. For slugs this is critical: café-au-lait should become cafe-au-lait, not get percent-encoded into something unreadable. The converter handles this automatically using the normalize('NFD') API available in all modern browsers.

Consecutive separators are another gotcha. Input like my---variable__name should not produce my---variable__name in slug form. Collapsing all separator runs into a single space before tokenising is the cleanest approach, and it handles the common case of copy-pasted text with extra spaces too.

Quick Reference

Keep this somewhere visible when you're jumping between codebases in different languages:

• JS/TS variables → camelCase
• JS/TS classes, React components → PascalCase
• CSS → kebab-case
• Python all-the-things (except classes) → snake_case
• Constants, env vars → SCREAMING_SNAKE_CASE
• URLs → slug (kebab + sanitised)
• Config namespaces → dot.case

Case conventions look trivial until you're two hours into debugging a property name mismatch or fighting a linter rule you didn't realise was enforcing PascalCase for component files. Getting this right from the start costs nothing — a quick conversion takes under a second with the right tool.