camelCase vs snake_case vs kebab-case: Naming Conventions Explained

Developers use several naming styles for variables, file names, URLs, database columns, API fields, and class names.

The most common include:

camelCase
snake_case
kebab-case
PascalCase
Title Case
UPPER CASE
lower case

Duck Cloud's Case Converter converts text between common naming styles locally in your browser.

camelCase

Example:

userProfileImage

camelCase is common in JavaScript and many API conventions.

The first word begins lowercase, while later words begin with capitals.

It is useful where spaces and hyphens are not valid identifier characters.

PascalCase

Example:

UserProfileImage

PascalCase capitalizes the first word too.

Common uses include:

• class names;
• React component names;
• type names;
• certain language conventions.

Follow the convention of the language and codebase rather than inventing a new rule per file.

snake_case

Example:

user_profile_image

snake_case uses underscores between words.

It is widely seen in:

• Python variables and functions;
• SQL database columns;
• configuration fields;
• APIs.

Database teams often prefer it because it remains readable without relying on case sensitivity.

kebab-case

Example:

user-profile-image

kebab-case uses hyphens.

It is especially common for:

• URL slugs;
• CSS class naming conventions;
• file names;
• command-line options.

Hyphens generally cannot be used directly in many programming-language identifiers because they may be interpreted as subtraction.

Title Case

Example:

User Profile Image

Title Case is for human-facing text rather than machine identifiers.

Headings, labels, and article titles may use it depending on editorial style.

Do not convert user-facing language mechanically without reviewing grammar and proper nouns.

Naming conventions in APIs

APIs should be consistent.

A response that mixes:

{
  "user_id": 1,
  "displayName": "Isaac",
  "profile-image": "..."
}

creates unnecessary client complexity.

Choose one convention for your API contract and document it.

Changing field naming later can be a breaking API change.

Database naming

Database identifiers should be predictable across tables.

For example:

created_at
updated_at
user_id
order_id

are easy to understand as a consistent family.

Avoid requiring developers to remember whether one table uses createdAt and another uses created_at.

URL naming

Public page slugs usually work well with lowercase hyphenated words:

/how-to-format-json

Use Duck Cloud's Slug Generator for title-to-slug conversion.

A URL slug is related to kebab-case, but URL design also includes SEO, stability, length, and internationalization considerations.

Acronyms can be tricky

How should you convert:

HTTP API URL

Possible codebase styles include:

httpApiUrl
HTTPApiURL
http_api_url

There is no universal answer. Consistency with the project's existing convention is more valuable than personal preference.

Automated conversion needs review

A case converter can quickly normalize lists of field names or generate candidate identifiers.

However, review:

• acronyms;
• brand names;
• numbers;
• Unicode;
• punctuation;
• established API fields.

Changing case can change meaning in case-sensitive systems.

Naming checklist

• Follow the language's ecosystem.
• Follow the existing repository convention.
• Keep API fields consistent.
• Keep database columns predictable.
• Use kebab-case-style slugs for many public URLs.
• Do not rename public API fields casually.
• Review acronyms.
• Automate repetitive conversion, then inspect the result.

Naming conventions are small decisions repeated thousands of times. Consistency is what turns those decisions into a maintainable codebase.