Case Converter
Converts identifiers between camelCase, PascalCase, snake_case, kebab-case and CONSTANT_CASE.
—
—
—
—
—
—
—
—
When to use each convention
| Convention | Example | Where it's used |
|---|---|---|
| camelCase | customerProfile | Variables and methods (JavaScript/TypeScript, Java) |
| PascalCase | CustomerProfile | Classes, React components, types |
| snake_case | customer_profile | Python, Ruby, database columns (SQL) |
| kebab-case | customer-profile | URLs, CSS classes, npm packages |
| CONSTANT_CASE | CUSTOMER_PROFILE | Constants and environment variables |
What case conversion is
Every language and context has its own convention for naming identifiers: JavaScript variables typically use camelCase, classes use PascalCase, database columns often use snake_case, and URLs/CSS use kebab-case. This tool takes an identifier in any of these forms and generates the others automatically — useful when porting a name across languages, or adapting a value coming from an API to your own code's convention.
How the tool identifies words
Before generating any format, the tool first breaks the input identifier into a list of words — using explicit separators (_, -, ., /, space) and uppercase/digit transitions as clues. Acronyms (like XML, API, HTTP) are recognized as a single word and, when rebuilt into camelCase/PascalCase, become a Capitalized word like any other (XMLHttpRequest → xmlHttpRequest) — keeping the acronym fully uppercase would break the format's own convention. The caption below the input field shows exactly the words identified.
Known limitations
A fully flat identifier, with no separator and no uppercase letter (e.g. "customdata"), gives the tool no signal to split on — it becomes a single token. Stylized names that look like acronyms but aren't (OAuth, GraphQL, iOS, macOS) follow the same mechanical rule as any real acronym, with no special handling — the alternative would be an endless list of exceptions for proper nouns, which the tool deliberately doesn't have.
Frequently asked questions
The tool treats every identified acronym (XML, in this case) as a normal word when rebuilding camelCase/PascalCase — it becomes "Xml", Capitalized like any other word, never kept fully uppercase. Preserving the original acronym would break camelCase's own rule when it appears at the start of the identifier.
There's no signal at all (separator, case change, digit) indicating where one word ends and the next begins. Splitting it correctly would require checking against a dictionary of known words — an extra dependency and a source of unpredictable results the tool chose not to have.
"OAuth" isn't a real acronym — it's a stylized name ("Open" + "Auth"). The tool has no way of knowing that: it applies the same mechanical rule to any run of two or more uppercase letters, splitting it into "O" + "Auth". Adding an exception for "OAuth" would open the door to an endless list of other stylized names (GraphQL, iOS, npm...) — this is documented, expected behavior, not a bug.
No — a digit never gets a separator before it, only after (when followed by a real word). That's why "userID2" becomes "user_id2" (not "user_id_2") and "html5Parser" becomes "html5_parser" — the same way these names actually appear in practice.
By combining explicit separators (space, _, -, ., /) with three kinds of transition: lowercase followed by uppercase, an acronym followed by a new word, and a letter followed by (or preceded by) a digit. The "Interpreted as" caption shown below the input field, as soon as there's text, shows exactly the word list identified for your input.
This tool was designed for code identifiers — variable, function, class names — not natural-language sentences. Formats like Title Case and Sentence Case were deliberately left out of this version for that exact reason: capitalizing a sentence correctly depends on linguistic rules (which small words stay lowercase, for example) that don't exist for an identifier, and applying this tool's tokenization logic to a sentence can lose information (an acronym inside the text, for example).