What is camel case?
camelCase joins words into a single token: the first word is all lowercase, and every following word starts with a capital — “user last name” becomes “userLastName”. The name comes from the uppercase humps rising out of the lowercase text. Its sibling PascalCase (UpperCamelCase) capitalizes the first word too: “UserLastName”.
Because it packs meaning into one valid identifier, camelCase is the standard naming convention in JavaScript, Java, TypeScript, and Swift for variables and functions — and for keys in JSON documents. Typing it by hand means deleting spaces, fixing caps, and hunting hyphens; this converter does the whole transformation in one click, stripping punctuation and joining what remains.
camelCase for programmers
Paste a list with one name per line and each line converts independently — handy when you are turning a column of spreadsheet headers into API field names, or a feature list into function names. “max retry count” becomes “maxRetryCount”; “user-profile-pic” becomes “userProfilePic”.
Need the snake_case convention instead (Python, SQL, env vars)? One click on the snake_case mode converts the same input that way. The live preview lets you compare both forms before copying, and the .txt download drops your converted list straight into your editor.
Where camelCase came from
The style is older than most people assume. Charles Simonyi — the Hungarian programmer who later led the development of Word and Excel at Microsoft — used intercap naming in his doctoral work around 1976–77, and brought the habit with him to Xerox PARC, where he wrote one of the earliest widely circulated documents describing the approach. When he joined Microsoft, the technique grew into what became known as Hungarian notation, where a prefix like sz or lpcstr encodes a variable’s type before the camel-capped descriptive name follows. That prefix part has largely fallen out of favor, but the intercap core — meaning packed into one identifier with capital letters marking word boundaries — survived everywhere.
The nickname itself took a while to stick. Programmers called the style “intercap” or “mixed case” through the eighties and nineties; the camel imagery appeared in early Usenet discussions and was firmly popularized around 1995, not least because WikiWikiWeb — the first wiki, built by Ward Cunningham — ran on a mechanism that auto-linked any CamelCase words written in a page. Once a generation of developers learned to write ThisVeryPhrase to create hyperlinks, the name was settled. Today it reads as ordinary code convention, though it is worth remembering it was once an explicit style decision that teams argued about at length.
Naming variables and functions in JavaScript and Java
JavaScript and Java settled on camelCase for nearly everything you declare by hand. Variables and functions in JS follow it almost without exception — getUserById, orderTotal, isEmailVerified — and the language’s built-in APIs reinforce the habit, from getElementById to addEventListener. Java is even more rigid about it: the official Oracle naming conventions specify camelCase for methods and fields, and reserve PascalCase for classes and interfaces. A Java developer who writes Get_Data() or fetchuser() will hear about it in code review within the hour, and linters at most companies enforce the rule automatically.
The conventions encode meaning through the shape of the name, not just its spelling. Verbs open function names because functions do things — calculateInvoice, sendReminder, parseCsvFile. Booleans read as predicates: isValid, hasChildren, canRetry, which is why the words is, has, can, and should appear so often at the front of variable names. Constants in JavaScript get the ALL_CAPS treatment (MAX_RETRIES), while in Java regular fields stay camelCase. If you are converting a phrase list into function names, remember that camelCase output works best once you have decided the leading verb — “retry count” is a variable, “retry count check” is a method called checkRetryCount.
JSON APIs: snake_case on the server, camelCase on the client
One of the most common friction points in modern development is that the two sides of an API speak different case conventions. Python, Ruby, and Rust backends default to snake_case field names, and most relational databases store columns as snake_case — so the raw JSON a server emits reads user_created_at. JavaScript and Swift clients, on the other hand, follow their own language conventions and expect userCreatedAt. Somewhere between the wire and your component code, every field name needs its case flipped, and a real payload can carry dozens of fields.
Teams resolve this mismatch in one of three ways: they configure the serializer once at the boundary (Python’s pydantic, Ruby’s ActiveModel Serializers, and Rust’s serde can all emit camelCase automatically), they normalize in a thin mapping layer on the client, or they simply hand-convert the names when writing fixtures, type definitions, and mock data. The third path is where a converter earns its keep — paste the server’s snake_case list, read back camelCase, and you have your TypeScript interface or test fixture without touching the case of thirty-two fields by hand. Consistency matters more than which side wins the argument; the API style guides published by Google, Microsoft, and AWS all settle on camelCase for JSON precisely because so many clients expect it.
Java getters and setters: camelCase at industrial scale
Java’s bean convention multiplies camelCase names fast. A field called firstName is accessed through getFirstName() and mutated through setFirstName(), and for a boolean field the getter is is- prefixed — isActive() for a field called active. Every one of those method names is just the field name run through camelCase with a verb glued on the front, which is why IDEs handle it: in IntelliJ IDEA you generate getters and setters with a keyboard shortcut (Alt+Insert on Windows and Linux, Cmd+N on macOS), and the dialog derives every method name from the camelCase field you already wrote. Lombok’s @Getter and @Setter annotations and Java records push the same idea further by removing the boilerplate entirely — but the names the tools invent still follow the camelCase rules.
The convention ripples outward beyond Java itself. Jackson serializes Java objects to JSON using those getter names, so a camelCase method becomes a camelCase JSON key automatically — until someone adds a mismatched annotation and the API starts emitting FirstName for one field out of two hundred. Frameworks from Spring to Android’s data binding look up properties by these camelCase names. Getting the casing right at the field level is therefore not cosmetic; the whole toolchain from database row to JSON response to client model assumes it, and a converter is the quick way to produce matching name sets when you are defining a schema or filling in a data class by hand.
camelCase vs PascalCase vs snake_case vs kebab-case
The four styles differ in where the capital letters go and what sits between the words, and each has carved out its own territory. camelCase (getUserById) is variables, functions, and JSON keys in the C-family and web world. PascalCase (GetUserById) is class and component names — Java classes, React components, TypeScript interfaces, .NET public members. snake_case (get_user_by_id) rules Python, SQL columns, environment variables, and most database work. kebab-case (get-user-by-id) owns URLs, HTML data-attributes, CSS class names, and file names, because it is the only one of the four that stays lowercase while remaining readable in contexts where underscores are invisible or illegal.
URLs are the case where the comparison gets genuinely practical. Domains and paths are case-insensitive in practice but conventionally lowercase, so kebab-case wins; paste camelCase into a slug and you get a mixed-bag link nobody can read aloud over the phone. Meanwhile kebab-case is unusable as a JavaScript identifier — the hyphen parses as subtraction — which is exactly why a React project ends up with kebab-case file names wrapping PascalCase components containing camelCase props sending snake_case database keys. Every conversion in that sentence is mechanical, which is why the multi-tool at /case-converter exists alongside this page: same input, all four outputs, pick the one each layer of the stack demands.
Enforcing camelCase with linters
Manually keeping hundreds of identifiers in one convention does not scale, which is why linters carry the rule instead of people. ESLint’s camelcase rule flags any JavaScript or TypeScript variable, property, or import that drifts from the convention, and most shared configs — eslint-config-airbnb, next/core-web-vitals, the configs generated by create-react-app — enable it by default. The rule accepts options for which contexts to check and lets you permit certain names, which matters because a few exceptions are always legitimate: names handed to you by an external API, properties accessed with bracket notation, or constants copied straight from a spec document.
Other ecosystems have their equivalents. Python projects configure pep8-naming to keep identifiers in snake_case, Java teams use Checkstyle, and Swift’s linter SwiftLint warns on function names that are not lowerCamelCase. What all of them share is the underlying assumption that the convention is decided once and then enforced mechanically — the human job is choosing names that describe intent, not remembering which letter to capitalize. When you are onboarding a legacy codebase to a linter, a converter helps with the cleanup phase: export the offending names, fix them in bulk, and let the rename-refactoring tool carry the change through the codebase rather than editing call sites by hand.
TypeScript interfaces and type names
TypeScript adds a second naming layer on top of JavaScript’s variables and functions. Interfaces and type aliases use PascalCase — UserProfile, OrderSummary, ApiResponse<T> — while the fields inside them use camelCase, matching whatever JSON the type models. So a typical declaration reads: interface UserProfile, with fields firstName, lastName, dateOfBirth, isVerified. The type name is PascalCase but every member is camelCase, and generic parameters conventionally use single capital letters, T and K and V. The public type definitions published by API SDKs all follow this two-tier pattern, which is one reason reading a well-typed SDK feels so predictable.
The practical workflow shows up when you paste a JSON response into a TypeScript project and need the interface to match. JSON keys are usually already camelCase if the server was configured for JS clients, but a Python or Rails backend hands you snake_case keys — firstName stays firstName, but date_of_birth needs to become dateOfBirth, and every property in your interface has to match the wire format exactly or the compiler starts reporting undefined fields. Converting the server’s key list to camelCase in one paste gives you an interface skeleton you can annotate with types, instead of editing thirty property names one keystroke at a time and hoping you did not skip one.
A conversion story: renaming fields for a new API client
A concrete example makes the workflow clear. A team ships a Django backend whose JSON responses use snake_case everywhere — order_id, created_at, customer_full_name, total_amount_in_cents. Mobile development starts, and the Swift team’s style guide requires camelCase properties to match the rest of the iOS codebase. Nobody wants to argue about which side should change; instead the contract team sits down with the full field list — 40 fields across the order endpoints — and converts the whole list from snake_case to camelCase in one pass. The result becomes the canonical field mapping in the API documentation, and the iOS models and the Android data classes are both written against the converted names.
The alternative is doing it field by field inside an editor, which is where the bugs come from: one developer writes totalAmountInCents, another writes totalamountincents, a third accidentally converts customer_full_name into customerFull_Name with a stray underscore, and the decoding layer silently drops the field at runtime. Mechanical conversion of the complete list first — then writing code against that list — eliminates the whole class of error. This is exactly the batch workflow this page is built for: paste one name per line, get one converted name per line back, download the file, and treat it as the single source of truth for the rename. Teams that do this before writing client code spend minutes; teams that do not spend their first integration sprint debugging misspelled keys.