JavaScript Variable Name Converter
camelCase writes helloWorldExample. JavaScript uses camelCase for variables, functions, properties and method names, reserving PascalCase for classes and constructor functions. The convention comes from the language itself: every built-in method, from toLowerCase to getElementById, is camelCase, so matching it makes your code indistinguishable in style from the platform.
Conversions
| Input | camelCase |
|---|---|
hello world example | helloWorldExample |
XMLHttpRequest | xmlHttpRequest |
user_first_name | userFirstName |
Total Order Count | totalOrderCount |
XMLHttpRequest splits into XML, Http, Request, so camelCase gives xmlHttpRequest — the leading acronym lower-cases entirely while the inner one keeps its shape. Naive converters produce xMLHttpRequest, which is what the browser API is actually called and is widely considered a mistake in the original spec.The Same Text in Other Cases
| Case | Result |
|---|---|
| PascalCase | HelloWorldExample |
| snake_case | hello_world_example |
| SCREAMING_SNAKE_CASE | HELLO_WORLD_EXAMPLE |
| kebab-case | hello-world-example |
| Train-Case | Hello-World-Example |
| dot.case | hello.world.example |
The Platform Sets the Convention
Every built-in method is camelCase — toLowerCase, getElementById, addEventListener — so matching it makes your code visually indistinguishable from the language itself. The exceptions are informative: constructors and classes are PascalCase, and SCREAMING_SNAKE marks module-level constants.
One genuine trap: JSON keys arriving from a snake_case backend do not become camelCase by themselves. Converting at the boundary keeps the convention intact inside your code; converting ad hoc leaves both spellings alive in the same file.
Converting in Code
``javascript
const camel = (s) =>
words(s)
.map((w, i) => (i === 0 ? w.toLowerCase() : w[0].toUpperCase() + w.slice(1).toLowerCase()))
.join('');
`
The first word is the special case. Every implementation that forgets it produces TotalCount instead of totalCount, which in Go would export the identifier and in JSON would break a field name consumers already depend on.
Converting at the API Boundary
The recurring friction is that JavaScript uses camelCase and Python, Ruby, Go and SQL use
snake_case. The fix is to convert in exactly one place — the client that talks to the API —
rather than letting both conventions into the same codebase.
`javascript
const toCamel = (s) => s.replace(/_([a-z])/g, (_, c) => c.toUpperCase());
const toSnake = (s) => s.replace(/[A-Z]/g, (c) => '_' + c.toLowerCase());
// Recursively, for a whole payload
const convertKeys = (value, fn) =>
Array.isArray(value)
? value.map((v) => convertKeys(v, fn))
: value && typeof value === 'object'
? Object.fromEntries(Object.entries(value).map(([k, v]) => [fn(k), convertKeys(v, fn)]))
: value;
`
Two things to watch: keys that are user data rather than field names must not be
converted, and the round trip is not always lossless — userID → user_id → userId
changes the original.
Where Each Convention Is Mandatory
Not stylistic — these will break if you deviate:
| Context | Requirement |
|---|---|
| Environment variables | Uppercase with underscores; POSIX reserves lowercase |
| Custom HTML elements | Must contain a hyphen |
| Python modules | Cannot contain hyphens; the import statement will not parse |
| SQL identifiers | Folded to one case unless quoted, so camelCase does not survive |
| React components | Must start uppercase, or JSX treats it as an HTML tag |
Renaming Safely
A find-and-replace across a codebase will hit strings, comments and unrelated identifiers.
Use your language server's rename symbol instead — it understands scope. For a bulk rename
across files, restrict the pattern with word boundaries and review the diff before
committing:
`bash
grep -rn '\buserId\b' src/ # look first
``