camelCase vs snake_case vs kebab-case: Which Naming Case Goes Where

The convention map is short: camelCase for JavaScript/Java variables, snake_case for Python and SQL, kebab-case for URLs and CSS, PascalCase for classes, CONSTANT_CASE for constants. Follow it and your code reads like everyone else’s — cross it and every code review starts with the same comment. Convert anything between cases in one click with the case converter.

The five cases, defined

A naming case is a rule for writing multi-word identifiers where spaces aren’t allowed:

Case	Example	Home turf
camelCase	userLoginCount	JavaScript, Java, Swift variables & functions
PascalCase	UserLoginCount	Classes, types, C# methods, React components
snake_case	user_login_count	Python, Ruby, Rust, SQL columns
kebab-case	user-login-count	URLs, CSS classes, HTML attributes, file names
CONSTANT_CASE	USER_LOGIN_COUNT	Constants, environment variables

Why each ecosystem picked its case

These aren’t arbitrary tastes — each convention solves a local problem:

• JavaScript/Java (camelCase): inherited from Smalltalk-era style; the lowercase start visually separates variables from PascalCase classes at a glance.
• Python (snake_case): PEP 8, Python’s official style guide, chose underscores for readability — user_login_count parses faster for humans than userLoginCount, and Python’s culture prizes readability above brevity.
• CSS/HTML (kebab-case): HTML is case-insensitive, so fontSize and fontsize collide — hyphens sidestep the problem entirely, which is why CSS properties (font-size) and ARIA attributes (aria-label) are hyphenated.
• SQL (snake_case): many databases fold unquoted identifiers to one case, destroying camelCase distinctions; underscores survive.
• Constants (CONSTANT_CASE): the all-caps shout is a warning label — “this value never changes.”

The one hard rule with SEO consequences sits in URLs: Google’s URL-structure documentation recommends hyphens over underscores because hyphens are treated as word separators while underscores can join words. /my-blue-widget/ reads as three words; /my_blue_widget/ may read as one. That’s why the slug generator defaults to hyphens.

Converting between cases (without retyping)

The case converter splits input on spaces, hyphens, underscores and existing capital-letter boundaries — so conversions work in every direction:

1. Paste userLoginCount → pick snake_case → user_login_count (moving JS logic to Python).
2. Paste Blog Post Title Here → pick kebab-case → blog-post-title-here (or use the dedicated slug generator, which also strips accents and symbols).
3. Paste a whole column of identifiers, one per line — each converts independently.

Worked example — migrating a JS config to environment variables: apiBaseUrl → CONSTANT_CASE → API_BASE_URL. One paste, one click, no typos.

Common naming-case mistakes

1. Mixing cases in one codebase — getUser() next to fetch_user() costs every future reader a double-take. Match whatever the file already does.
2. Underscored URLs — /blog_post_title/ hurts both consistency and how search engines parse the words. Hyphens, always.
3. camelCase CSS classes — they work until someone’s tooling lowercases them. Kebab-case is the ecosystem norm.
4. Renaming halfway — converting user_id to userId in some files but not the query layer creates the classic “works locally” bug. Convert systematically (the find & replace tool with match-case on helps audit).
5. Acronym ambiguity — parseHTMLString vs parseHtmlString: pick one treatment of acronyms and stick to it; most modern style guides prefer Html.

Quick summary

Match the ecosystem: camelCase in JavaScript, snake_case in Python and SQL, kebab-case in URLs and CSS, PascalCase for classes, CONSTANT_CASE for constants — and hyphens in URLs are an SEO-grade rule, not a preference. For any conversion, the case converter handles all five (plus a few joke ones), and the slug generator covers the URL case end-to-end.

Related: character counter for length limits on the names · find & replace for codebase-wide renames.