camelCase is a naming convention where multiple words are joined without spaces, and each word after the first begins with an uppercase letter. The first word always starts with a lowercase letter.

The name comes from the visual appearance: the capital letters in the middle of the identifier resemble the humps of a camel rising above the lowercase body of the word.

• ▸getUserById
• ▸isAuthenticated
• ▸handleButtonClick
• ▸fetchApiResponse
• ▸myVariableName
• ▸numberOfRetries

Every word after the first has its initial letter capitalized. All other letters stay lowercase. No underscores, no hyphens, no spaces — just the capital letters marking word boundaries.

JavaScript and TypeScript: camelCase is the established convention for variable names, function names, method names, and object properties. It is used by every major style guide — Airbnb, Google, and the TypeScript team all specify camelCase for these identifiers. It is not enforced by the JavaScript runtime, but linters like ESLint will flag violations in most configured codebases.

Java: camelCase is the official convention for variable names and method names, as defined in the original Java Code Conventions. Java class names use PascalCase, but everything else — local variables, parameters, instance variables, and method names — uses camelCase.

JSON: Most JSON APIs return data with camelCase keys — userId, firstName, createdAt, isActive. This is because JSON is most commonly consumed by JavaScript, which expects camelCase. When a Python or Ruby backend translates snake_case database fields into a JSON response, it typically converts them to camelCase for the frontend.

Swift: Apple's Swift language uses camelCase for variable names, function names, and enum cases. The Swift API Design Guidelines explicitly require camelCase for these identifiers.

Kotlin: Like Java, Kotlin uses camelCase for variables, functions, and properties, with PascalCase reserved for class and object names.

The most common point of confusion is between camelCase and PascalCase. The only difference is the very first letter: camelCase starts with a lowercase letter; PascalCase starts with an uppercase letter.

camelCase: getUserById, handleClick, myVariable

PascalCase: UserService, HandleClick, MyComponent

In most languages, camelCase is for values and behaviors — variables and functions. PascalCase is for types and blueprints — classes, interfaces, and components. In React, this distinction is functional: a component written as <userCard /> will not render because React treats lowercase-starting JSX elements as HTML tags. Only <UserCard /> signals a custom React component.

The rule of thumb: if it holds data or does something, use camelCase. If it defines a structure or type, use PascalCase.

snake_case uses underscores as separators with all lowercase letters: get_user_by_id, is_authenticated, handle_button_click. The two formats carry the same information — only the delimiter differs.

The choice between them is language-driven, not personal preference. JavaScript, Java, Swift, and Kotlin use camelCase for variables and functions. Python, Ruby, Rust, and SQL use snake_case.

This creates a common translation problem in web development: JavaScript frontends use camelCase JSON keys (firstName, createdAt), while Python and PostgreSQL backends use snake_case columns (first_name, created_at). Developers and ORMs regularly convert between the two at the API boundary.

A key technical note: underscores are valid identifier characters in every major language, which is why snake_case works everywhere. In contrast, hyphens are subtraction operators in most languages — which is why kebab-case cannot be used for variable names.

React hooks are a particularly important camelCase context because they have a required naming constraint. Every custom React hook must start with the word 'use' followed by a camelCase identifier — useEffect, useState, useCallback, useReducer, useFetchData, useLocalStorage.

This is not purely stylistic: React's linter rules and the React compiler detect hooks by looking for this use + camelCase pattern. A hook named UseFetchData or fetch_data will not be recognized as a hook and will not follow the hook rules correctly.

React's official documentation is explicit: 'Its name must start with use followed by a capital letter.' This makes camelCase a functional requirement for hook naming, not just a convention.

The most common real-world use for a camelCase converter is translating between data formats and languages. A database column named user_profile_image (snake_case) needs to become userProfileImage (camelCase) when surfaced in a JavaScript API response. Doing this manually across dozens of field names is error-prone and slow.

Other common scenarios: converting human-readable descriptions into variable names ('number of failed attempts' → numberOfFailedAttempts), translating Python function names into JavaScript equivalents, and generating consistent naming when scaffolding new code.