Text Case Styles Explained: camelCase, snake_case, Title Case and When to Use Each

The first time I reviewed a junior developer's pull request and found variable names in four different styles on the same screen, I realised how few people are ever taught the rules behind text case. We all absorb camelCase and snake_case by osmosis, copy whatever the surrounding code does, and hope for the best. But each style exists for a reason, and using the right one makes code and content noticeably easier to read.

This guide walks through the main case styles, where each one belongs, and how to switch between them without retyping a single character.

The case styles you will actually meet

There are only a handful worth memorising, and once you can name them, you start seeing them everywhere.

• camelCase — first word lowercase, every later word capitalised: firstName, totalPrice. The humps in the middle give it its name.
• PascalCase (also called UpperCamelCase) — like camelCase but the first letter is capital too: FirstName, UserProfile.
• snake_case — all lowercase, words joined by underscores: first_name, total_price.
• kebab-case — all lowercase, words joined by hyphens: first-name, hero-banner.
• Title Case — each major word capitalised, used in headings: "How to Name Things Well".
• UPPER_SNAKE_CASE — all caps with underscores, traditionally for constants: MAX_RETRIES.

They all encode the same words. The only thing that changes is how you mark the boundaries between them.

Where each style belongs

Conventions are not arbitrary — they are shared agreements that let a team read code without friction.

camelCase and PascalCase

In JavaScript, Java and many C-style languages, camelCase is the norm for variables and functions, while PascalCase is reserved for classes, components and types. In React, for example, a component must be PascalCase (UserCard) so the library can tell it apart from a plain HTML tag. Mixing these up is one of the most common beginner mistakes.

snake_case

Python's style guide (PEP 8) prefers snake_case for variables and functions, and it is also the overwhelming convention for database column names. Underscores survive being lowercased by a database and read cleanly in SQL, which is why created_at looks natural and createdAt looks out of place in a table.

kebab-case

You cannot use spaces or capitals reliably in URLs, CSS class names or file names, so kebab-case steps in. A blog URL like /text-case-styles-explained is readable, SEO-friendly and safe across every filesystem and server. If you need to turn a title into a URL, a URL slug generator does exactly this conversion.

Converting between styles without retyping

Here is the scenario that used to waste my time: a designer hands over a list of labels in Title Case, and I need them as camelCase keys for a config file. Retyping forty labels by hand is slow and introduces typos.

The reliable fix is to let a tool do the boundary detection. A case converter splits your text on spaces, underscores, hyphens and capital letters, works out the underlying words, then rejoins them in whatever style you pick. Paste "User Profile Settings", choose camelCase, and you get userProfileSettings instantly.

For the two conversions developers hit most often, there are dedicated tools: camelCase to snake_case is perfect when you are mapping JavaScript objects to database columns, and snake_case to camelCase handles the reverse when you read a Python API response into a JS front end.

A quick worked example

Say an API returns { "user_id": 1, "first_name": "Sam" } in snake_case, but your TypeScript interface expects camelCase. Rather than editing each key, run the field list through a converter and you get userId and firstName in one pass. On a payload with twenty fields, that is the difference between five seconds and five minutes — and zero chance of a typo slipping through.

A simple rule of thumb

When you are unsure which style to use, ask one question: what will read this?

• A database or Python → snake_case.
• A browser URL, CSS class or filename → kebab-case.
• A JavaScript variable or function → camelCase.
• A class, component or type → PascalCase.
• A heading a human reads → Title Case.
• A constant that never changes → UPPER_SNAKE_CASE.

The goal is consistency within each context. A file that mixes getUser, get_user and GetUser for the same idea is harder to scan than one that picks a lane and stays in it, even if the lane is not your personal favourite.

Why this small thing matters

Naming is one of the few parts of writing software that pays off every single time someone reads your work. Consistent case is a quiet signal that the author cares about the details, and it removes a tiny hesitation from every line. Multiply that across a large codebase and it adds up to real readability.

You do not need to memorise every rule today. Bookmark a converter, follow the surrounding convention, and let the tool handle the mechanical part. Spend your attention on choosing good words — that is the genuinely hard part of naming, and no tool can do it for you.