Skip to content

Naming cases, explained

A name can carry the same words and still look different depending on where it appears. userProfileId, user_profile_id, user-profile-id, and UserProfileId all say roughly the same thing, but each style belongs to a different habit, language, framework, or file format.

Those styles are called naming cases. They matter because code, URLs, CSS classes, JSON fields, database columns, and generated files often follow different conventions. A name that looks natural in JavaScript may look wrong in SQL. A name that works well as a CSS class may not work as a variable.

Converting between cases looks simple until acronyms, separators, numbers, and existing punctuation get involved. This guide explains the common cases, where they show up, and what can go wrong when you convert names in bulk.

Common naming cases

camelCase

camelCase starts with a lowercase word and capitalizes each following word. 

userProfileId
invoiceTotalAmount
createdAt

You will see it often in JavaScript variables, JSON field names, and many API payloads.

PascalCase

PascalCase capitalizes every word, including the first. 

UserProfileId
InvoiceTotalAmount
CreatedAt

It is common for class names, component names, type names, and constructor-style identifiers.

snake_case

snake_case uses lowercase words separated by underscores. 

user_profile_id
invoice_total_amount
created_at

It is common in Python, SQL column names, CSV headers, and many data exports.

kebab-case

kebab-case uses lowercase words separated by hyphens. 

user-profile-id
invoice-total-amount
created-at

It often appears in URLs, CSS class names, file names, command-line flags, and web-friendly slugs.

Other related styles

You may also see SCREAMING_SNAKE_CASE for constants, Title Case for headings, and lowercase space-separated text for normal prose.

The details vary by project, but the reason for all of them is the same: names need to fit the place they live.

Where naming cases show up

Different environments prefer different shapes.

JavaScript code often uses camelCase for variables and PascalCase for classes or React components. CSS often uses kebab-case for class names. Databases often use snake_case for table and column names. URLs often use kebab-case because hyphens are readable and search-friendly. Environment variables often use uppercase snake case.

Data moves between all of those places. A backend might return created_at from a database while a frontend wants createdAt. A design system might name a component PrimaryButton while the CSS class is primary-button. An export might turn object keys into CSV headers and then import them somewhere else.

That is why case conversion tools exist. They help with repetitive name changes, but they cannot always infer intent.

Acronyms and initialisms

Acronyms are the most annoying part of naming cases.

Should it be apiUrl, APIUrl, apiURL, or ApiUrl? Different teams choose different answers.

A few common patterns:

  • JavaScript style often favors apiUrl for a variable
  • PascalCase type names might use ApiUrl or APIUrl, depending on team style
  • snake_case usually becomes api_url
  • kebab-case usually becomes api-url

The danger is inconsistency. If a codebase has both userID and userId, searches get noisier and generated mappings can break.

For bulk conversion, decide on the acronym policy before changing hundreds of names.

Separators, numbers, and punctuation

Case conversion starts by splitting text into words. That sounds easy, but inputs can be messy.

These all need interpretation: 

User ID
user_id
user-id
user.ID
user2FAStatus
HTTPResponseCode

A converter has to decide where one word ends and the next begins. Numbers can be part of a word, a separator, or a signal that a new word starts. Dots and slashes may mean structure, not just punctuation.

That is why converted output should be reviewed before it gets committed to code or imported into a database.

A worked example: one phrase through several cases

Start with this phrase: 

API response status code

A reasonable conversion set might be: 

camelCase: apiResponseStatusCode
PascalCase: ApiResponseStatusCode
snake_case: api_response_status_code
kebab-case: api-response-status-code
SCREAMING_SNAKE_CASE: API_RESPONSE_STATUS_CODE

Notice the acronym choice. This example treats API as a word that becomes api in camelCase and Api in PascalCase. Another team might prefer APIResponseStatusCode for PascalCase.

Neither is universally right. The important part is that your project picks a convention and sticks to it.

Try it in your browser

Our Case Converter runs locally in your browser. Paste a phrase, field name, or list of names, then convert between camelCase, snake_case, kebab-case, PascalCase, and other common styles.

That local workflow is useful when you are working with draft API fields, database columns, config keys, or internal naming plans that should not be uploaded just to change separators and capitalization.

Common mistakes

Converting acronyms without a team rule. userID, userId, and userid may all appear after different tools or developers touch the same code.

Changing public API fields casually. Renaming created_at to createdAt can break clients that depend on the old shape.

Treating punctuation as harmless. Dots, slashes, and colons may carry structure in paths, object keys, or namespaces.

Mixing URL slugs and code identifiers. A URL can use hyphens. A JavaScript variable cannot.

Bulk-renaming without search and tests. Names connect files, queries, docs, and clients. Review the diff before shipping changes.

FAQ

camelCase starts with a lowercase first word. PascalCase capitalizes the first word too.

Use it where your language, database, or team convention expects underscore-separated names. Python and SQL workflows commonly use it.

Hyphens are readable in URLs and avoid the awkward look of underscores in many link contexts.

Pick one project rule. For example, apiUrl and ApiUrl are easier to keep consistent than mixing APIURL, apiURL, and ApiURL.

For simple text, yes. For real code, be careful. Renaming identifiers can affect imports, templates, database mappings, and external clients.

Related guides