By Rohit V.8 min readArticle
camelCase vs snake_case vs kebab-case: A Dev Guide
TF
ToolsFuel Team
Web development tools & tips
Photo by Unsplash on Unsplash
Table of Contents
What are the main casing styles?
Every codebase has an unspoken argument running through it about how to glue words together in a name. I've walked into projects where the casing was a free-for-all, and it's genuinely harder to read than code with consistent-but-'wrong' casing.
> Quick answer: The four you'll meet constantly are camelCase (`firstName`), PascalCase (`FirstName`), snake_case (`first_name`), and kebab-case (`first-name`). There's also SCREAMING_SNAKE_CASE for constants. Each language and context has a convention: camelCase for JavaScript variables, PascalCase for classes and components, snake_case for Python, and kebab-case for URLs, CSS, and file names where you can't use underscores or capitals reliably. If you just need to flip a name between styles, the case converter does it instantly.
The names are literal once you see them. camelCase has a hump in the middle. PascalCase capitalizes every word. snake_case slithers along the ground with underscores. kebab-case is skewered with hyphens. The rest of this is about which one belongs where, because using the wrong style in the wrong place is what gets flagged in code review.
> Quick answer: The four you'll meet constantly are camelCase (`firstName`), PascalCase (`FirstName`), snake_case (`first_name`), and kebab-case (`first-name`). There's also SCREAMING_SNAKE_CASE for constants. Each language and context has a convention: camelCase for JavaScript variables, PascalCase for classes and components, snake_case for Python, and kebab-case for URLs, CSS, and file names where you can't use underscores or capitals reliably. If you just need to flip a name between styles, the case converter does it instantly.
The names are literal once you see them. camelCase has a hump in the middle. PascalCase capitalizes every word. snake_case slithers along the ground with underscores. kebab-case is skewered with hyphens. The rest of this is about which one belongs where, because using the wrong style in the wrong place is what gets flagged in code review.
When do you use camelCase vs PascalCase?
These two are the same idea — join words, capitalize the boundaries — split only by whether the very first letter is capital. That one difference carries a surprising amount of meaning in most languages.
camelCase, lowercase first letter, is the default for variables, function names, and object properties in JavaScript, Java, and C#. `userName`, `getTotal`, `isActive` — anything that holds a value or does a thing. It reads as 'this is a regular identifier.'
PascalCase, capital first letter, signals something bigger: a class, a type, a constructor, or a React component. `UserProfile`, `HttpClient`, `OrderService`. The capital letter is a convention that tells other developers 'this is a type or a component, not a plain variable.' React leans on this hard — a lowercase component name is treated as an HTML tag, so `<userProfile />` silently breaks while `<UserProfile />` works. I've lost a good ten minutes to exactly that typo. The casing isn't cosmetic there; it changes behavior.
camelCase, lowercase first letter, is the default for variables, function names, and object properties in JavaScript, Java, and C#. `userName`, `getTotal`, `isActive` — anything that holds a value or does a thing. It reads as 'this is a regular identifier.'
PascalCase, capital first letter, signals something bigger: a class, a type, a constructor, or a React component. `UserProfile`, `HttpClient`, `OrderService`. The capital letter is a convention that tells other developers 'this is a type or a component, not a plain variable.' React leans on this hard — a lowercase component name is treated as an HTML tag, so `<userProfile />` silently breaks while `<UserProfile />` works. I've lost a good ten minutes to exactly that typo. The casing isn't cosmetic there; it changes behavior.
Where does snake_case fit?
snake_case swaps the capital-letter boundaries for underscores, so everything stays lowercase and words are separated by `_`. It's the house style of a few big ecosystems, and using it there makes your code look native.
Python is the headline user — PEP 8, Python's style guide, calls for snake_case for variables and functions (`user_name`, `calculate_total`). Ruby uses it too, and it's the standard for SQL column and table names (`created_at`, `order_items`). Databases love it because SQL is case-insensitive in a lot of setups, so relying on capital letters to separate words is asking for trouble; underscores survive.
The screaming variant, SCREAMING_SNAKE_CASE, is the near-universal convention for constants — values that never change, like `MAX_RETRIES` or `API_BASE_URL`. You'll see it in almost every language, including ones that otherwise use camelCase, and it's exactly how keys look in a .env file. The all-caps shout is the point: it tells you at a glance 'don't reassign this.'
Python is the headline user — PEP 8, Python's style guide, calls for snake_case for variables and functions (`user_name`, `calculate_total`). Ruby uses it too, and it's the standard for SQL column and table names (`created_at`, `order_items`). Databases love it because SQL is case-insensitive in a lot of setups, so relying on capital letters to separate words is asking for trouble; underscores survive.
The screaming variant, SCREAMING_SNAKE_CASE, is the near-universal convention for constants — values that never change, like `MAX_RETRIES` or `API_BASE_URL`. You'll see it in almost every language, including ones that otherwise use camelCase, and it's exactly how keys look in a .env file. The all-caps shout is the point: it tells you at a glance 'don't reassign this.'
Why is kebab-case everywhere on the web?
kebab-case uses hyphens between lowercase words, and it shows up in the places where the other styles literally can't. The hyphen is the tell, and there's a hard technical reason it wins on the web rather than just taste.
Most programming languages treat a hyphen as a minus sign, so `first-name` in JavaScript reads as `first minus name` — you can't name a variable that way. That knocks kebab-case out of code identifiers entirely. But in contexts that aren't code identifiers, it shines: URLs (`/blog/my-post`), CSS class names (`.nav-item`), HTML attributes, and npm package names all use kebab-case. Search engines also read hyphens in URLs as word separators, so kebab-case slugs are better for SEO than cramming words together.
File names are the other big home for it, especially on the web, because hyphens dodge the case-sensitivity mismatch between operating systems. A file named `My-Component.css` versus `my-component.css` can break a deploy when a case-insensitive Mac talks to a case-sensitive Linux server. Lowercase kebab-case sidesteps the whole class of bug, which is why so many teams standardize on it for assets.
Most programming languages treat a hyphen as a minus sign, so `first-name` in JavaScript reads as `first minus name` — you can't name a variable that way. That knocks kebab-case out of code identifiers entirely. But in contexts that aren't code identifiers, it shines: URLs (`/blog/my-post`), CSS class names (`.nav-item`), HTML attributes, and npm package names all use kebab-case. Search engines also read hyphens in URLs as word separators, so kebab-case slugs are better for SEO than cramming words together.
File names are the other big home for it, especially on the web, because hyphens dodge the case-sensitivity mismatch between operating systems. A file named `My-Component.css` versus `my-component.css` can break a deploy when a case-insensitive Mac talks to a case-sensitive Linux server. Lowercase kebab-case sidesteps the whole class of bug, which is why so many teams standardize on it for assets.
Which convention should you actually pick?
The honest rule is boring but correct: follow the convention of the language or framework you're in, not your personal preference. Consistency inside a codebase beats any individual style being 'better.'
So write Python in snake_case, JavaScript in camelCase, name your React components in PascalCase, and use kebab-case for URLs, CSS, and files. If you're contributing to an existing project, match what's already there even if you'd have chosen differently — a file that mixes styles is the actual readability problem, not which style won. Linters like ESLint and Ruff exist largely to enforce this automatically, so you don't have to police it by hand.
Where people trip is at the boundaries between systems. Your JavaScript uses camelCase, but the JSON from your API comes back in snake_case because the backend is Python. You either convert at the boundary or accept a little mismatch. I usually normalize once, right where the data enters my code, so the rest of the app stays consistent. When I need to bulk-rename a pile of keys from one style to another, pasting them through the case converter beats hand-editing every one and fat-fingering half of them.
So write Python in snake_case, JavaScript in camelCase, name your React components in PascalCase, and use kebab-case for URLs, CSS, and files. If you're contributing to an existing project, match what's already there even if you'd have chosen differently — a file that mixes styles is the actual readability problem, not which style won. Linters like ESLint and Ruff exist largely to enforce this automatically, so you don't have to police it by hand.
Where people trip is at the boundaries between systems. Your JavaScript uses camelCase, but the JSON from your API comes back in snake_case because the backend is Python. You either convert at the boundary or accept a little mismatch. I usually normalize once, right where the data enters my code, so the rest of the app stays consistent. When I need to bulk-rename a pile of keys from one style to another, pasting them through the case converter beats hand-editing every one and fat-fingering half of them.
How do you keep casing consistent across a project?
The hardest casing problems aren't inside one file — they're at the seams between systems that each have their own convention. A Python backend hands your JavaScript frontend a payload full of snake_case keys, your frontend wants camelCase, and your database columns are snake_case underneath all of it. Nobody's wrong; they're each following their own house style.
I handle this by converting once, at the boundary where data crosses. When an API response comes in, I normalize the keys to camelCase right there, so the rest of my frontend stays consistent and I'm never guessing which style a given object uses. Doing it in scattered spots is how you end up with `user.firstName` in one component and `user.first_name` in another, both half-working.
Config and environment values are their own little world. Environment variables are SCREAMING_SNAKE_CASE almost everywhere by convention, so `DATABASE_URL` and `API_KEY` look the same across every language and shell. That consistency is a feature — it makes env vars instantly recognizable regardless of the codebase they sit in.
Style guides codify all of this so teams don't relitigate it per project. Python's PEP 8 is the canonical example, spelling out snake_case for functions and PascalCase for classes, and most languages have an equivalent. When you're unsure what's idiomatic, the language's official style guide is the tiebreaker, and following it makes your code look like it belongs. The goal isn't the 'best' style in the abstract — it's matching the room you're in, then converting cleanly at the edges where rooms meet. One more boundary worth naming is the file system itself. Git tracks a rename that only changes case unreliably, and a case-insensitive Mac will happily let `Header.css` and `header.css` coexist until a case-sensitive Linux build server treats them as two different files and the deploy breaks. Sticking to lowercase kebab-case for file names sidesteps that whole category of works-on-my-machine bug, which is why so many teams enforce it in a linter.
I handle this by converting once, at the boundary where data crosses. When an API response comes in, I normalize the keys to camelCase right there, so the rest of my frontend stays consistent and I'm never guessing which style a given object uses. Doing it in scattered spots is how you end up with `user.firstName` in one component and `user.first_name` in another, both half-working.
Config and environment values are their own little world. Environment variables are SCREAMING_SNAKE_CASE almost everywhere by convention, so `DATABASE_URL` and `API_KEY` look the same across every language and shell. That consistency is a feature — it makes env vars instantly recognizable regardless of the codebase they sit in.
Style guides codify all of this so teams don't relitigate it per project. Python's PEP 8 is the canonical example, spelling out snake_case for functions and PascalCase for classes, and most languages have an equivalent. When you're unsure what's idiomatic, the language's official style guide is the tiebreaker, and following it makes your code look like it belongs. The goal isn't the 'best' style in the abstract — it's matching the room you're in, then converting cleanly at the edges where rooms meet. One more boundary worth naming is the file system itself. Git tracks a rename that only changes case unreliably, and a case-insensitive Mac will happily let `Header.css` and `header.css` coexist until a case-sensitive Linux build server treats them as two different files and the deploy breaks. Sticking to lowercase kebab-case for file names sidesteps that whole category of works-on-my-machine bug, which is why so many teams enforce it in a linter.
Frequently Asked Questions
What is the difference between camelCase and PascalCase?
Both join words and capitalize boundaries; the only difference is the first letter. camelCase starts lowercase (`userName`) and is used for variables and functions, while PascalCase starts uppercase (`UserProfile`) and is used for classes, types, and components.
Why can't I use kebab-case for variable names?
Most languages read the hyphen as a minus sign, so `first-name` parses as subtraction, not a name. That's why kebab-case is used for URLs, CSS classes, and file names instead of code identifiers. You can convert names between styles with the [case converter](/tools/case-converter).
What casing should I use for constants?
SCREAMING_SNAKE_CASE — all uppercase with underscores, like `MAX_RETRIES`. It's the near-universal convention for values that never change, and it's exactly how environment variable keys look in a [.env file](/blog/what-is-a-dot-env-file-environment-variables-explained).
Is snake_case or camelCase better for a database?
snake_case, because SQL is often case-insensitive, so relying on capital letters to separate words is unreliable. Underscores survive case-folding, which is why columns like `created_at` are the norm.
Does the naming convention actually matter or is it just style?
Mostly it's convention, but sometimes it changes behavior — React treats a lowercase component name as an HTML tag, so casing there is functional, not cosmetic. Beyond that, consistency within a codebase is what matters most for readability.
Try ToolsFuel
23+ free online tools for developers, designers, and everyone. No signup required.
Browse All Tools