camelCase vs snake_case vs kebab-case Explained

Sooner or later, every programmer ends up in an argument about naming. Should it be userId or user_id? MyComponent or my-component? These choices feel arbitrary, but they aren't — each naming convention has a name, a history, and a set of places where it's the accepted standard. Pick the right one and your code reads like it belongs; pick the wrong one and it announces itself as out of place. Here's a tour of all the major styles and where each one earns its keep.

The four main conventions

A few others exist — SCREAMING_SNAKE_CASE, Train-Case, dot.case — but these four cover the overwhelming majority of real-world use. You can convert text between all of them instantly with the Case Converter.

camelCase

The first word is lowercase, and every word after it starts with a capital, with no separators in between:

firstName
getUserById
isActive
maxRetryCount

camelCase is the standard for JavaScript and TypeScript variables and functions, Java variables and methods, C# local variables and parameters, JSON keys (often, especially when a JS backend produced them), and Swift and Kotlin variables. The Google JavaScript Style Guide puts it plainly: local variable names and method names are written in lowerCamelCase. If you write JavaScript, camelCase is your default for everything except classes and constants.

PascalCase

Same as camelCase, except the first word is capitalized too:

UserAccount
HttpClient
MyComponent
OrderService

PascalCase is the convention for class and type names in nearly every language — JS, TS, Java, C#, Python, Swift, you name it — as well as React and Vue components (<MyComponent />), C# methods and public members (where it diverges from Java and JS), and namespaces or modules in some ecosystems.

The pattern that holds across most languages is worth memorizing: PascalCase for types and classes, camelCase for instances and variables. So you write const userAccount = new UserAccount().

snake_case

All lowercase, with words separated by underscores:

first_name
get_user_by_id
is_active
max_retry_count

snake_case is the standard for Python variables, functions, and methods, Ruby variables and methods, Rust variables and functions, SQL column and table names by convention, database fields in general, and C variables in many style guides. For Python it's not just a habit — it's the rule. PEP 8, the official Python style guide, states that "function names should be lowercase, with words separated by underscores," and that variables follow the same convention. If you write Python, snake_case is your default for variables and functions — with PascalCase (CapWords, in PEP 8's terms) for classes.

SCREAMING_SNAKE_CASE

SCREAMING_SNAKE_CASE is the loud, all-uppercase variant of snake_case, and it's the near-universal convention for constants and environment variables:

MAX_CONNECTIONS
API_BASE_URL
DEFAULT_TIMEOUT

This one crosses language lines cleanly. PEP 8 says Python constants are "written in all capital letters with underscores separating words," and the Google JavaScript Style Guide uses the same shape under the name CONSTANT_CASE.

kebab-case

All lowercase, with words separated by hyphens:

first-name
user-profile
main-content
my-component

kebab-case lives in URLs and slugs (/blog/my-first-post), CSS class names (.nav-bar, .btn-primary), HTML attributes (data-user-id), file names in many projects (web ones especially), npm package names (react-dom, tailwind-merge), and command-line flags (--dry-run). The slug for this very page is kebab-case. If you generate slugs or other identifiers programmatically, you may also reach for a UUID when you need guaranteed uniqueness instead of a readable name.

One catch worth knowing: kebab-case can't be used for variable names in most languages, because the hyphen reads as a minus sign — user-id parses as user minus id. That's why kebab-case stays confined to contexts where the name is just a string: URLs, CSS, filenames.

Which to use where: a cheat sheet

Why consistency matters more than the choice

Here's the honest truth: most of these conventions are about equally readable. What actually matters is consistency within a context. Mixing userId and user_name in the same object is jarring, and worse, it's error-prone. The conventions exist so that a few good things happen:

You stop having to think about it — the ecosystem decides for you. Your tools keep working — linters, formatters, and ORMs all assume a convention. And bugs surface faster, because user_id versus userId mismatches are a classic source of mystery undefined values when data crosses a boundary, like a snake_case database feeding a camelCase JavaScript frontend.

That last point is very real. Plenty of APIs convert between snake_case (the database side) and camelCase (the JavaScript side) right at the boundary, and forgetting to do the conversion produces silent undefined values that take ages to track down.

Converting between conventions

When you're porting code, renaming variables, or reshaping data between a snake_case backend and a camelCase frontend, you have to convert names. Doing it by hand for more than a few identifiers is tedious and, predictably, error-prone.

The Case Converter converts any text to all the conventions at once — paste a name, click the style you want, copy the result. It tokenizes correctly on existing word boundaries (spaces, hyphens, underscores, and case changes), so getUserById round-trips cleanly to get_user_by_id and back. And if you're cleaning up a list of identifiers — say, column names pulled from a CSV export — pair it with the Remove Duplicate Lines tool to dedupe first.

If you'd rather script the conversion in your editor, a single find-and-replace with a capture group does most of the work — see regex flags explained for the global and case-insensitive switches that make a bulk rename behave.

What the readability research actually says

The research is genuinely mixed, which is itself the useful finding: no style is a clear winner. Researchers at Kent State and elsewhere ran a set of controlled experiments — including eye-tracking — comparing camelCase and underscore styles, and the results cut both ways.

The 2010 eye-tracking study "An Eye Tracking Study on camelCase and under_score Identifier Styles" by Sharif and Maletic found a significant improvement in time and visual effort with the underscore style — the underscores separate words the way spaces do, so your eye finds the boundaries faster. An earlier timed study had found that camelCase produced slightly higher accuracy and that developers trained in camelCase recognized those identifiers faster. A later, larger replication, "The impact of identifier style on effort and comprehension" (Binkley, Davis, Lawrie, Maletic, Morrell, and Sharif, 2013), found no accuracy difference between the styles, though camel-cased identifiers took meaningfully longer to read on average.

So: snake_case may be a touch easier on the eyes, camelCase is more compact, training matters, and the overall gap is small. The honest takeaway is that consistency and familiarity outweigh the objectively "best" choice. Follow your language's convention and don't lose sleep over it.

The bottom line

camelCase (userId) is for JS, Java, and C# variables. PascalCase (UserId) is for classes and components everywhere. snake_case (user_id) is for Python, Ruby, SQL, and databases. kebab-case (user-id) is for URLs, CSS, filenames, and packages, and SCREAMING_SNAKE_CASE is for constants and environment variables. But the meta-lesson outranks all of them: consistency within a context matters more than which convention you pick. When you need to switch between them, the Case Converter handles all of them at once.