camelCase vs snake_case — Which Naming Convention to Use and When

camelCase and snake_case are both ways of writing compound identifiers without spaces. The debate over which is better has consumed untold developer-hours on Stack Overflow and in code reviews. Here’s what the evidence and convention actually say.

Use the Case Converter to convert between camelCase, snake_case, PascalCase, kebab-case, and other conventions instantly.

What is camelCase?

camelCase joins words by capitalizing the first letter of each word after the first, with no separator. The name comes from the hump-like appearance of the capital letters in the middle.

• getUserById
• totalWordCount
• isAuthenticated
• parseJsonString

lowerCamelCase (the common form): first word lowercase, subsequent words capitalized. UpperCamelCase / PascalCase: all words capitalized, including the first — GetUserById, TotalWordCount. Often used for class names and types.

What is snake_case?

snake_case joins words with underscores, all lowercase (typically). Named for the flat, snake-like appearance.

• get_user_by_id
• total_word_count
• is_authenticated
• parse_json_string

SCREAMING_SNAKE_CASE: all uppercase — MAX_RETRY_COUNT, DEFAULT_TIMEOUT_MS. Used for constants.

Which languages use which convention

This is not a style preference — in most languages there is a community-wide convention. Deviating from it means your code looks wrong to experienced readers of that language.

Languages that use camelCase for variables and functions

Language	Variables/Functions	Classes
JavaScript / TypeScript	camelCase	PascalCase
Java	camelCase	PascalCase
C#	camelCase (local vars)	PascalCase
Swift	camelCase	PascalCase
Kotlin	camelCase	PascalCase
Go	camelCase (private)	PascalCase (exported)
Dart	camelCase	PascalCase

Languages that use snake_case for variables and functions

Language	Variables/Functions	Classes
Python	snake_case	PascalCase
Ruby	snake_case	PascalCase
Rust	snake_case	PascalCase
C	snake_case (conventional)	N/A (no classes)
PHP	Mixed (camelCase in Laravel, snake_case in some projects)	PascalCase

Database conventions

SQL column names use snake_case by strong convention across PostgreSQL, MySQL, and SQLite:

• created_at, user_id, first_name, is_active

Using camelCase column names in a relational database (createdAt, userId) is technically valid but considered non-standard. Most ORM frameworks (Django ORM, SQLAlchemy, Eloquent) map snake_case DB columns to camelCase model properties automatically.

URL and file conventions

URLs and file names for web assets use kebab-case (hyphen-separated lowercase):

• /tools/case-converter/
• hero-image.webp
• app-main.js

CSS class names also use kebab-case:

• .btn-primary, .nav-header, .card-body

Readability research

The question of which convention produces faster reading has been studied empirically.

Bonita Sharif and Jonathan Maletic (2010) studied 135 programmers and found that snake_case produced 20% faster reading comprehension than camelCase. The proposed explanation: underscores are visual word separators that match how humans parse word boundaries in natural text.

Counter-argument: A 2012 study at Loyola University found no statistically significant difference in comprehension between the two styles for experienced programmers, but did find that training matters — programmers read whichever style they’re familiar with faster.

Practical conclusion: Use the convention of the language you’re writing in. If you’re Python developer writing JavaScript, you’ll slow down temporarily — but your team will read your code fine, and you’ll acclimate.

When the choice actually matters

API design

If you’re building a public JSON API, pick a convention and stick to it. The JavaScript ecosystem expects camelCase in JSON (userId, createdAt). Some APIs use snake_case (Twitter’s API v1 used snake_case; v2 shifted to camelCase).

Whatever you choose: document it explicitly, apply it consistently across all endpoints, and don’t mix within the same API.

Cross-language boundary: serialization

When a Python backend (snake_case) communicates with a JavaScript frontend (camelCase), you need a conversion layer. Options:

Option 1: Convert at the API boundary (recommended)

Python Pydantic models with camelCase alias:

from pydantic import BaseModel, Field, alias_generator
from pydantic.alias_generators import to_camel

class User(BaseModel):
    user_id: int
    created_at: str
    
    model_config = {'alias_generator': to_camel, 'populate_by_name': True}

# Serializes to: {"userId": 1, "createdAt": "2026-05-11"}

Option 2: snake_case in JSON, convert on the frontend

// Convert snake_case JSON to camelCase in JavaScript
function snakeToCamel(obj) {
  if (Array.isArray(obj)) return obj.map(snakeToCamel);
  if (obj && typeof obj === 'object') {
    return Object.fromEntries(
      Object.entries(obj).map(([k, v]) => [
        k.replace(/_([a-z])/g, (_, c) => c.toUpperCase()),
        snakeToCamel(v)
      ])
    );
  }
  return obj;
}

Converting between cases in code

camelCase to snake_case

import re

def camel_to_snake(name):
    # Insert _ before capital letters (handle consecutive caps: HTMLParser → html_parser)
    s1 = re.sub('([A-Z]+)([A-Z][a-z])', r'\1_\2', name)
    s2 = re.sub('([a-z\d])([A-Z])', r'\1_\2', s1)
    return s2.lower()

camel_to_snake('getUserById')     # 'get_user_by_id'
camel_to_snake('HTMLParser')      # 'html_parser'
camel_to_snake('totalWordCount')  # 'total_word_count'

snake_case to camelCase

def snake_to_camel(name):
    parts = name.split('_')
    return parts[0] + ''.join(p.capitalize() for p in parts[1:])

snake_to_camel('get_user_by_id')    # 'getUserById'
snake_to_camel('total_word_count')  # 'totalWordCount'

JavaScript: both directions

// snake_case → camelCase
const snakeToCamel = s => s.replace(/_([a-z])/g, (_, c) => c.toUpperCase());

// camelCase → snake_case
const camelToSnake = s => s.replace(/([A-Z])/g, c => `_${c.toLowerCase()}`);

// camelCase → kebab-case
const camelToKebab = s => s.replace(/([A-Z])/g, c => `-${c.toLowerCase()}`);

snakeToCamel('get_user_by_id')    // 'getUserById'
camelToSnake('getUserById')       // 'get_user_by_id'
camelToKebab('getUserById')       // 'get-user-by-id'

Common edge cases in case conversion

Acronyms

How should “HTML” appear in camelCase? Conventions differ:

• htmlParser (treat acronym as a regular word — preferred in JavaScript, Go)
• HTMLParser (keep acronym uppercase — common in older Java/C# code)

Python’s naming guide (PEP 8) recommends treating acronyms as regular words: html_parser, json_data, xml_node.

Numbers

Numbers in identifiers: base64Decode, sha256Hash, utf8String. Most conventions treat numbers as transparent — they don’t cause word boundaries. base64 is one “word” in identifier naming.

Conversion edge case: sha256 → snake_case → sha256 (no conversion needed, no uppercase letters). sha256Hash → snake_case → sha256_hash (capital H triggers the split).

Single-letter words

getId, setX, isA — these are valid camelCase with single-letter “words.” Snake_case: get_id, set_x, is_a. The single-letter words (a, x, etc.) are unusual in real identifier names but appear in mathematical code.

The Case Converter tool

The Case Converter handles all standard naming conventions: lowercase, UPPERCASE, Title Case, Sentence case, camelCase, PascalCase, snake_case, SCREAMING_SNAKE_CASE, and kebab-case. Paste your identifiers, select the target convention, and copy the result. It also handles common edge cases like consecutive uppercase letters (HTML → html) correctly.

Related tools

• Case Converter — convert between all naming conventions
• Text Diff — compare two identifier lists after renaming
• Regex Tester — write and test regex patterns for case conversion