Comparison

camelCase vs snake_case vs kebab-case: When to Use Each Naming Convention

Every language, framework, and format has its preferred way of joining multi-word identifiers. Mixing them within one codebase looks unprofessional; using the wrong one for a given context actively breaks things — kebab-case is not a valid variable name in most languages, snake_case attributes fail in CSS.

This guide is not about which is “best”. It is about which is the correct choice given a specific language or file type, and the historical reasons those conventions crystallized.

TL;DR

	camelCase	PascalCase	snake_case	kebab-case	CONSTANT_CASE
Example	userName	UserName	user_name	user-name	USER_NAME
Primary language	JavaScript, Java, Swift	C#, Java classes	Python, Rust, Ruby, SQL	CSS, URLs, HTML attrs	C constants, env vars
Valid variable name	Yes	Yes	Yes	No	Yes
Common for	Variables, functions	Classes, types	Vars, DB columns	URLs, file names, CSS	Constants, env vars

The options in depth

camelCase

Lowercase first, uppercase each subsequent word. The default in JavaScript and Java.

The oldest and most widespread convention for variable and function names in curly-brace languages. Chosen originally because it compressed identifiers without the underscores of snake_case, matching the terser style of C-family languages.

Good for

·JavaScript / TypeScript variables and functions
·Java / Kotlin / Swift variables and methods
·JSON API keys when clients are JavaScript-heavy

Avoid when

·Python (use snake_case)
·URLs (use kebab-case)
·SQL column names (use snake_case, since most databases fold identifiers to lowercase)

Try it: Case Converter →

PascalCase (UpperCamelCase)

camelCase with the first letter capitalized. Reserved for classes and types.

PascalCase visually separates “types” from “values” — in Java, C#, TypeScript, and many others, PascalCase is class / interface / type names, while camelCase is variables and methods. This convention is remarkably universal.

Good for

·Class names in Java, TypeScript, C#, Swift, Kotlin, Rust
·React component names (compilers use the leading capital as the JSX signal)

Avoid when

·Variables (use camelCase)
·Constants (use CONSTANT_CASE)

snake_case

Words joined by underscores. Python and databases love it.

snake_case is Python's PEP 8 mandate for variables and functions. It is also the near-universal SQL identifier convention because most databases fold unquoted identifiers to lowercase, making userName and username ambiguous.

In Ruby, JSON APIs targeted at Python/Ruby clients, and shell script variables, snake_case is the expected style.

Good for

·Python variables / functions
·SQL column and table names
·JSON API keys when clients are Python/Ruby-heavy
·Ruby method names
·Rust functions and variables (PascalCase for types)

Avoid when

·JavaScript (use camelCase, unless matching a snake_case API)
·URLs (use kebab-case — hyphens are search-engine friendly)

Try it: Case Converter →

kebab-case

Words joined by hyphens. Optimal for URLs, files, and CSS.

Hyphens are impossible in most identifiers because they collide with the subtraction operator. That is exactly why they are perfect in contexts that are not code: URLs (Google prefers hyphens over underscores for readability), file names, and CSS properties.

Good for

·URLs and slugs (/blog/my-first-post)
·File names (my-component.tsx)
·CSS custom properties (--brand-color)
·HTML attribute names (data-user-id)

Avoid when

·Any variable name in almost any language (hyphen = subtraction)

Try it: Case Converter →

CONSTANT_CASE (SCREAMING_SNAKE)

All caps with underscores. The universal signal for constants and env vars.

Reserved for compile-time constants (`const MAX_RETRIES = 3` in Java) and environment variables (`DATABASE_URL`, `NODE_ENV`). The uppercase makes it visually distinct at a glance — this identifier is a value that will not change.

Good for

·Environment variables
·Compile-time / static constants in Java, C, Kotlin
·Enum values in many languages (though Rust prefers PascalCase)

Avoid when

·Regular variables (feels shouty)

Which one should you pick?

→ Is this a URL, file name, or CSS property?

kebab-case. Hyphens are the web convention.

→ Is this a Python variable, function, or SQL column?

snake_case. PEP 8 for Python; SQL best practice for portability.

→ Is this a JavaScript / Java variable or function?

camelCase. Follow the language convention unless a specific API says otherwise.

→ Is this a class, type, or React component?

PascalCase. Universal across curly-brace languages.

→ Is this a compile-time constant or environment variable?

CONSTANT_CASE. The uppercase is the whole point.

Common pitfalls

⚠Do not translate an API's key case on the client side. If the server sends snake_case, keep it snake_case in your JavaScript to avoid every developer wondering which representation to use.
⚠Some languages (Ruby, Elixir) accept multiple conventions but the community strongly prefers one — follow the community, not the compiler.
⚠URLs with underscores are still valid but Google's guidance says hyphens are better for word separation. Rewriting is a permanent SEO change (301).
⚠Acronyms like `HTTP` in camelCase are ambiguous — is it `HTTPServer` or `HttpServer`? Pick one (Google's Java Style Guide prefers `HttpServer`) and be consistent.

Frequently Asked Questions

Why does Python not use camelCase?

PEP 8 (Python's style guide) chose snake_case because it is easier to read for identifiers with multiple words. This choice has been in place since Python 1.0.

Should JSON API keys use camelCase or snake_case?

Whichever matches the majority of consumers. camelCase if clients are mostly JavaScript / mobile; snake_case if clients are Python / Ruby / server-side. Pick one and be consistent — mixing is worst.

What about SCREAMING-KEBAB-CASE?

Exists (some HTTP headers use it: `Content-Type`, `Accept-Encoding`). Not used inside code because hyphens collide with subtraction.