Computers can’t read spaces inside an identifier, so every time programmers need a multi-word name — for a variable, a file, a CSS class, or a URL — they reach for a naming convention that joins the words without spaces. The three most common are camelCase, snake_case, and kebab-case. They’re not interchangeable: each has a home where it’s the standard, and using the wrong one marks code as out of place. This guide explains what each convention is, where it belongs, and how to pick.
The three conventions at a glance
| Convention | Example | How it works |
|---|---|---|
| camelCase | firstName | First word lowercase, each later word capitalized, no separators |
| PascalCase | FirstName | Like camelCase but the first word is capitalized too |
| snake_case | first_name | All lowercase, words joined by underscores |
| kebab-case | first-name | All lowercase, words joined by hyphens |
| SCREAMING_SNAKE_CASE | FIRST_NAME | All uppercase snake_case, used for constants |
The names are wonderfully literal. camelCase has humps in the middle from the capital letters. snake_case slithers along the ground connected by underscores. kebab-case looks like words skewered on hyphens. Once you picture them, you’ll never forget which is which.
camelCase
In camelCase, you write the first word in lowercase and capitalize the first letter of every subsequent word: getUserName, totalItemCount, isReady.
Where it’s used:
- JavaScript and TypeScript — variables, functions, object properties
- Java, C#, Swift — methods and variables
- JSON keys — very common, since JSON is consumed heavily by JavaScript
A close relative, PascalCase (also called UpperCamelCase), capitalizes the first letter too — UserProfile, HttpClient — and is conventionally reserved for class names, types, and components across most of these languages. So in a typical JavaScript file you’ll see PascalCase for the class and camelCase for its variables.
snake_case
In snake_case, every letter is lowercase and words are separated by underscores: user_name, total_item_count, is_ready.
Where it’s used:
- Python — the official style guide (PEP 8) mandates snake_case for variables and functions
- Ruby — variables and methods
- Rust — variables and functions
- Database columns — SQL table and column names are almost always snake_case
- C/C++ — common for variables in many codebases
snake_case is prized for readability because the underscores act like visible spaces. estimated_delivery_date is arguably easier to scan than estimatedDeliveryDate. Its uppercase variant, SCREAMING_SNAKE_CASE, is the near-universal convention for constants and environment variables: MAX_RETRIES, API_BASE_URL, DATABASE_URL.
kebab-case
In kebab-case, letters are lowercase and words are joined by hyphens: user-name, main-content, btn-primary.
Where it’s used:
- URLs and slugs —
/blog/camelcase-vs-snake-case/ - CSS class names —
.nav-item,.card-header - HTML attributes —
data-user-id - File names — many projects name files
my-component.js - npm package names —
react-router-dom
The one place kebab-case cannot go is inside most programming languages as a variable name, because the hyphen is read as a minus sign — user-name would be parsed as “user minus name.” That’s why kebab-case lives in URLs, markup, and filenames rather than in code logic. For URLs specifically, hyphens are also the SEO-preferred separator — Google treats them as word boundaries — which is why every clean URL slug uses kebab-case.
Which one should you use?
You rarely get to choose freely — the platform or language decides for you. The rule is follow the convention of whatever you’re writing in:
| If you’re naming… | Use… |
|---|---|
| A JavaScript/Java variable or function | camelCase |
| A class, type, or component | PascalCase |
| A Python or Ruby variable | snake_case |
| A database column | snake_case |
| A constant or environment variable | SCREAMING_SNAKE_CASE |
| A CSS class | kebab-case |
| A URL, slug, or filename | kebab-case |
The deeper principle is consistency within a context. A Python file should be uniformly snake_case; a CSS file uniformly kebab-case. Mixing conventions inside one file is the real mistake — far worse than picking the “wrong” convention consistently. When you import data across boundaries (say, snake_case database columns into a camelCase JavaScript app), pick a single point to convert between them rather than letting both styles leak everywhere.
Converting between conventions
Switching a name from one convention to another by hand is tedious and error-prone, especially across a long list of identifiers. A couple of text tools make it painless:
- To change capitalization patterns — for example, normalizing a list to all lowercase before adding separators — the case converter handles UPPERCASE, lowercase, Title Case, and Sentence case in one click.
- To turn a human-readable title into kebab-case for a URL or filename, the slug generator lowercases the text, strips punctuation, and joins words with hyphens automatically — exactly the transformation kebab-case needs.
If you’re working with structured data where keys follow a naming convention, the JSON formatter is handy for inspecting and tidying the result, and you can read more about the format itself in what is JSON.
A quick reference example
The same concept, “estimated delivery date,” across every convention:
camelCase: estimatedDeliveryDate
PascalCase: EstimatedDeliveryDate
snake_case: estimated_delivery_date
SCREAMING_SNAKE_CASE: ESTIMATED_DELIVERY_DATE
kebab-case: estimated-delivery-date
Notice that the words are identical — only the joining and capitalization change. That’s all these conventions are: different rules for gluing words together when spaces aren’t allowed.
The bottom line
camelCase (firstName) rules JavaScript and Java variables; snake_case (first_name) rules Python, Ruby, and database columns; kebab-case (first-name) rules URLs, CSS classes, and filenames. PascalCase handles classes and types, and SCREAMING_SNAKE_CASE handles constants. You almost never choose freely — you follow the convention of the language or platform, and you stay consistent within each file. To convert text between forms quickly, lean on the case converter and, for URL-ready kebab-case, the slug generator.
Frequently Asked Questions
What is the difference between camelCase, snake_case, and kebab-case?
All three join multiple words into one identifier without spaces. camelCase capitalizes each word after the first (firstName), snake_case lowercases everything and joins with underscores (first_name), and kebab-case lowercases everything and joins with hyphens (first-name). They’re used in different languages and contexts.
When should I use snake_case vs camelCase?
Follow the language’s convention. Use camelCase for JavaScript, Java, and C# variables; use snake_case for Python, Ruby, and database columns. The choice is dictated by the platform’s style guide, not personal preference — consistency within a codebase matters most.
Why can’t I use kebab-case in code?
In most programming languages, the hyphen is interpreted as a subtraction operator, so user-name would be read as “user minus name.” That’s why kebab-case is limited to URLs, CSS class names, HTML attributes, and filenames rather than variable names inside code.
What is PascalCase?
PascalCase (or UpperCamelCase) is like camelCase but with the first letter also capitalized — UserProfile, HttpClient. It’s conventionally used for class names, types, interfaces, and UI components in languages like JavaScript, Java, and C#.
What case should I use for URLs?
Use kebab-case (lowercase words joined by hyphens) for URLs and slugs. Search engines treat hyphens as word separators, so /my-blog-post/ is read correctly, whereas underscores and other separators are less reliable. The slug generator produces kebab-case automatically.
How do I convert text between these naming conventions?
Use the case converter to change capitalization (uppercase, lowercase, title case) and the slug generator to produce hyphenated kebab-case from a title. For bulk changes, converting the capitalization first and then adjusting separators is the quickest workflow.