How to Convert to camelCase (and Four Things That Trip People Up)
Lower camel case starts with a small letter, capitalises each following word and drops the separators. It is the default for JavaScript variables and most JSON fields, and usually the first thing to fix when aligning API field names.
Open the tool：camelCase Converter
When you actually need this
The API returns user_name, the front end wants userName, and the design file calls the same field User Name. Renaming three fields by hand is fine. Renaming forty in a row is how one gets missed, and a missed one surfaces later as undefined at runtime rather than as a visible error.
The other case is generating names from a table: spreadsheet headers, CSV column names or a list of English phrases that need to become variables or interface fields. Convert the whole batch first, then review acronyms and digits by hand — far steadier than typing each one.
- Converting snake_case API fields for front-end code
- Generating variable or type fields from table headers
- Normalising a batch of names to one case style
- Producing naming candidates while learning
What actually happens during conversion
There are two steps: lowercase everything, then replace each run of non-alphanumeric characters plus the character that follows with its uppercase form. Spaces, hyphens, underscores, dots and brackets all count as non-alphanumeric and disappear. So user profile, user-profile and user_profile all become userProfile.
The catch is that camel boundaries are not detected. Feed in userProfile and, after lowercasing, there is no separator left to split on, so the result is flattened to userprofile. The same happens to userID and APIKey: the capitalisation of acronyms is lost and has to be restored by hand.
- Normalise the input to space or hyphen separated first
- Insert separators into names that are already camelCase
- Restore acronyms such as ID, URL and API afterwards
- Digits join the neighbouring word: 3d model gives 3dModel
- Chinese characters are not alphanumeric and are removed
There is no single naming standard
The differences are real: JavaScript and Java use lowerCamelCase for variables and methods, C# uses PascalCase for public members, Python uses snake_case for variables and functions, and Go signals exported names with a leading capital. JSON is not standardised either — JavaScript projects lean on camelCase, while APIs such as Stripe and GitHub use snake_case.
So the output is a candidate, and your linter has the final say: ESLint's camelcase rule or PEP 8, for example. Mixing two styles inside one project is harder to maintain than picking either. The tool also will not decide between getHTTPResponse and getHttpResponse; that belongs in a team convention.
- Follow the project's lint configuration, not just the tool
- Keep one style within a project
- Fix acronym capitalisation by team convention
- Search for collisions with existing names after converting
FAQ
What is the difference between camelCase and PascalCase?
camelCase starts lowercase, as in userName, while PascalCase capitalises every word, as in UserName. JavaScript tends to use the first for variables and methods and the second for classes, components and types. Which applies depends on the language and the team.
Why did my userProfile turn into userprofile?
Because the conversion lowercases everything first, then splits on non-alphanumeric characters. userProfile has none, so the camel boundary is invisible and the whole string becomes one word. Write it as user profile or user_profile first to keep the words apart.
Why are some JSON fields camelCase and others snake_case?
Different ecosystems settled on different conventions. JavaScript projects tend to camelCase, while Python and Ruby projects and APIs such as Stripe use snake_case. Follow the documentation of the API you are integrating with, and avoid mixing both inside one payload.
Related tool：camelCase Converter