To convert snake_case to camelCase in JavaScript, split the string on underscores, lowercase every token, then keep the first token lowercase and capitalize the first letter of each following token, so user_first_name becomes userFirstName in a single pass. The hard part is not the casing rule but the tokenization step. Real identifiers mix acronyms such as XMLHttpRequest, digits like v2Endpoint, punctuation, and inconsistent casing (snake_case, kebab-case, PascalCase, ALL CAPS), and a naive regex that inserts an underscore before every capital letter turns XMLHttpRequest into x_m_l_http_request, which is not what you want. The Camel Case to Snake Case Converter handles that tokenization in one place by separating lower-to-upper transitions, splitting an acronym from the capitalized word that follows it, and treating any run of non-letters and non-digits as a token boundary. From a single deterministic token list it then assembles six naming styles at once, so the same input can be reformatted for variables, classes, env files, or display labels without re-pasting or re-tokenizing.
Why JavaScript projects meet snake_case in the first place
JavaScript itself prefers camelCase for local variables and functions, but the identifiers that arrive at a JavaScript codebase are not always written that way. Backends in Python, Ruby, and Go often expose JSON fields in snake_case. SQL databases typically store column names in snake_case. Environment variables are conventionally UPPER_SNAKE_CASE, and many REST APIs document payloads in snake_case for cross-language consistency. When a frontend, Node service, or TypeScript layer consumes those values, someone has to convert them before they match the rest of the codebase. The same task shows up when porting a library, normalizing data inside a hydration step, generating property names from a schema for an ORM, or renaming a slug imported from a CMS into a property a component can read.
That is the part people usually write a quick helper function for: take a string like user_first_name, split on _, lowercase each piece, and concatenate with the first letter of all but the first piece capitalized. The helper works for clean input and falls apart as soon as the identifier carries an acronym, a digit run, or punctuation that came in from a config file. At that point a one-line regex is not enough, and you want a tokenizer that already knows the rules for lower-to-upper transitions, acronym boundaries, and non-letter separators.
The snake_case to camelCase rule, plainly
The transformation rule itself is short. Given a snake_case identifier:
- Replace every run of separators (underscores, hyphens, spaces, dots, slashes) with a single token boundary.
- Lowercase every token so original casing no longer matters.
- For camelCase, keep the first token all-lowercase and uppercase the first letter of every later token, with no separator between them.
- For PascalCase, capitalize every token, again with no separator.
- For snake_case, kebab-case, and CONSTANT_CASE, rejoin the lowercase tokens with the appropriate separator and case.
- For Title Case, join with spaces and capitalize every token.
The rule produces, from the input user_first_name, the camelCase value userFirstName, the PascalCase value UserFirstName, and the snake_case value user_first_name. The same rule applied to API_RESPONSE_V2 gives apiResponseV2, ApiResponseV2, api_response_v2, api-response-v2, API_RESPONSE_V2, and Api Response V2. The interesting work is in step 1, where the tokenizer decides what counts as a token in the first place.
Tokenization is where most converters fail
Most case converters on the web apply a simple regex, usually something like s.replace(/([A-Z])/g, '_$1').toLowerCase(). That approach turns XMLHttpRequest into x_m_l_http_request, because it inserts a separator before every capital letter, including every letter inside an acronym. A correct tokenization for that input is xml_http_request, with three tokens: xml, http, request. Keeping XML together requires a rule that recognizes a run of capitals followed by a capitalized word as an acronym boundary, not a letter-by-letter split.
The Camel Case to Snake Case Converter applies two split rules in order. First it cuts at every lower-to-upper transition, which separates the c from I in userId into user and Id. Then it cuts at the boundary between a capital sequence and the capitalized word that follows it, which is what pulls XML away from Http in XMLHttpRequest. Any run of characters that is neither a Unicode letter nor a Unicode digit is treated as a separator and collapsed into a single boundary, so snake_case, kebab-case, and "snake case" all tokenize the same way. Digits stay inside the token they attach to where a boundary permits, so v2Endpoint becomes the tokens v2 and Endpoint rather than v, 2, Endpoint. Casing uses an explicit English locale so the result does not drift between machines configured with different user locales.
| Input | Tokens | camelCase | snake_case |
|---|---|---|---|
| user_first_name | user, first, name | userFirstName | user_first_name |
| XMLHttpRequest | xml, http, request | xmlHttpRequest | xml_http_request |
| v2_api_endpoint | v2, api, endpoint | v2ApiEndpoint | v2_api_endpoint |
| kebab-case-thing | kebab, case, thing | kebabCaseThing | kebab_case_thing |
All six outputs of the tool come from the same token list, which is why re-pasting the camelCase value into the converter produces the same snake_case, kebab-case, and CONSTANT_CASE values without any drift. This is also why the acronym policy of the destination project matters: userId and userID tokenize the same way and will both come back as userId, not as userID, unless your codebase adds the abbreviation back by hand.
Convert a snake_case identifier in the browser
- Paste the snake_case identifier, JSON field name, or short phrase into the input box of the Camel Case to Snake Case Converter.
- Review the tokenized list shown beneath the input. This is the part that decides whether XML stays together, whether v2 stays attached to endpoint, and whether punctuation from a config file turned into an empty token that broke the result.
- Pick the camelCase output for JavaScript variables, functions, and object properties. Pick PascalCase for classes and React components, kebab-case or snake_case for filenames, CONSTANT_CASE for module-level constants and environment variable names, and Title Case for human-readable labels.
- Copy the chosen value with the per-row copy control, paste it into the file you are editing, and run the project-specific rename and compatibility checks described in the next section.
The input is capped at five thousand code units, which is enough for a long identifier or a short phrase but not for a full file. Empty input or punctuation-only input is rejected because there is no convertible token. Whitespace and repeated separators collapse rather than producing empty words. The tool runs entirely in your browser through React, does not execute the pasted content, does not upload anything, does not store anything, and does not require a login or a package install.
Where camelCase belongs in a JavaScript codebase
Camel case is the dominant style for JavaScript identifiers that are not constants, classes, or React components. Local variables, function names, object properties accessed via dot notation, method names on classes, and the JSON keys you expose from your own API all use camelCase by convention. PascalCase is reserved for constructor functions, ES classes, and React component types so the JSX tag and the class name line up. CONSTANT_CASE is used for module-level constants, configuration switches, and environment variable values that you also read from a shell. Kebab-case is rare inside source files because the hyphen is interpreted as a minus operator in JavaScript, but it is common for filenames, slug-based routes, and CSS class names that JavaScript will read.
| Construct | Common style | Example |
|---|---|---|
| Local variable | camelCase | currentUserId |
| Function or method | camelCase | getUserProfile |
| Object property | camelCase | firstName |
| Class or React component | PascalCase | UserProfile |
| Module-level constant | CONSTANT_CASE | MAX_RETRY_COUNT |
| URL slug or CSS class | kebab-case | user-profile-card |
These are conventions, not language rules. A project may require snake_case for backend parity, or it may forbid leading digits in identifiers, or it may cap identifier length at a database column limit. The six outputs from the converter are mechanical transformations, and you still need to apply whatever policy your codebase actually enforces. For a wider comparison of the six styles in one view, see the camel case versus snake case guide.
Project-wide rename considerations
Reformatting one identifier in a single file is safe. Renaming an identifier across a project is a different task. A public symbol that is exported from a package, a database column that is read by other services, a JSON property consumed by a mobile app, an environment variable read by a deployment script, or a URL path that external clients bookmark all become breaking changes when their spelling changes, even when the new spelling looks cleaner. File systems and databases compare identifiers under their own case-sensitivity rules, so a rename that differs only by capitalization can need an intermediate name to avoid collisions or lost data.
The tool only transforms text. For real renames, use a language-aware refactoring tool for code, a database migration for columns, an alias or compatibility field for JSON, and a redirect or version bump for URLs. Run the type checker, the linter, the test suite, and a project-wide search for the old spelling before merging. Generated code, configuration files, ORM models, and reflection-driven code can hold references that even a good rename tool cannot see, so read the diffs and check the deployment order. The acronym policy in particular deserves attention: a project that expects userID may not want a converter that produces userId, and that is a project decision, not a tokenizer decision.
What this tool does and does not do
The converter tokenizes one identifier or short phrase at a time and returns the six disclosed naming styles. It preserves Unicode letters and numbers, applies an explicit English locale for casing so the result does not drift between machines, collapses repeated separators, and rejects empty or punctuation-only input. It does not transliterate scripts, singularize or pluralize words, spell-check, preserve punctuation, or guess at semantic abbreviations. user_id_number becomes userIdNumber, never a project-specific userIDNumber. It does not run inside your editor, does not commit to git, and does not rename across a repository. For JavaScript-specific testing while you iterate, the JavaScript Playground is a useful companion for trying a small helper against the converted value before you commit it.
Paste the value that matches your codebase, run the formatters and type checks your project already uses, and treat the rename as a deployment change rather than a rename. Everything runs locally, the input never leaves the browser, and no login or package is required to use it.