Case Converter — camelCase, snake_case, kebab-case & Title Case

What Is a Case Converter?

A case converter rewrites text from one naming convention to another: camelCase, snake_case, kebab-case, and Title Case. Each style takes the same underlying words and joins them with different capitalization and separator rules. The value of conversion is that different tools, languages, and platforms require different styles — a variable that is perfectly readable as my_variable_name in Python is illegal or convention-breaking in JavaScript, where the same identifier should be written myVariableName. Instead of retyping every identifier by hand, a case converter applies the rules instantly and consistently, which is faster and — more importantly — free of typos.

The Four Case Styles

Note that PascalCase (also called UpperCamelCase) — the convention for class names and React components — is the same as camelCase but with an uppercase first letter. Because Title Case capitalizes every word, converting hello world to Title Case gives you Hello World, and then removing the spaces by hand gives you PascalCase. This tool's camelCase output can be turned into PascalCase simply by capitalizing its first letter.

Why and When You Need a Case Converter

• Cross-language porting: moving code (or a data schema) between languages that use different conventions — e.g. adapting Python's snake_case API responses into JavaScript's camelCase objects.
• Database to code mapping: converting column names like created_at into the camelCase properties your ORM or frontend expects.
• CSS and file naming: turning a product name into a consistent kebab-case slug for class names, URLs, or image assets.
• Environment variables and configs: normalizing mixed-case input into one style before it is used as a key, flag, or identifier.
• Fixing legacy or imported data: cleaning up identifiers that were typed inconsistently (userName, user_name, USERNAME) into a single convention across a dataset.

How the Conversion Works

Conversion happens in two steps: tokenization, then re-joining. First the input is split into words. The tokenizer treats spaces, hyphens, underscores, dots, and slashes as word boundaries, and it also detects two invisible boundaries: an uppercase letter following a lowercase letter or digit (myVariable → my + Variable), and an acronym followed by a capitalized word (XMLParser → XML + Parser). This means the input can be written in any style and still convert correctly — the tool does not care whether you paste hello world, hello_world, hello-world, or helloWorld.

Then the words are re-joined: camelCase lowercases the first word and capitalizes each following word; snake_case and kebab-case lowercase everything and join with _ or -; Title Case capitalizes every word and joins with spaces. Because the tokenizer is what makes the output correct, the reference table below is the best way to see how edge cases like acronyms, digits, and mixed separators behave.

Step-by-Step: From Messy Input to Clean Output

Walking through one example shows exactly why the tokenizer matters. Take camelCaseXMLParser. First, the acronym rule inserts a space before Parser: camelCaseXML Parser. Then the camel boundary rule splits camelCase into camel Case, giving camel Case XML Parser. After separator normalization and splitting, the word list is ["camel", "Case", "XML", "Parser"]. From here each style is a simple join: camelCase lowercases the first word and capitalizes the rest (camelCaseXmlParser); snake_case and kebab-case lowercase every word and join with _ or - (camel_case_xml_parser, camel-case-xml-parser); Title Case capitalizes every word (Camel Case Xml Parser). Whatever messy style you paste in — mixed separators, leading or trailing whitespace, all caps, nested camel boundaries — the same pipeline normalizes it.

Naming Conventions Across Languages and Platforms

Conventions are not arbitrary — they are the established rules of each ecosystem, usually enforced by linters and code review. Writing in the wrong style for the platform is a common source of churn in pull requests, so converting to the local convention before committing saves everyone time.

Reference Table

Paste any row's input into the tool above to confirm the four outputs match, or use the converter to double-check a naming question before it goes into a codebase.

Troubleshooting & Practical Tips

Conversion Is Lossy — Keep Your Original

The converter cannot recover the exact input once it has been converted, because multiple inputs map to the same output (both hello world and hello_world become helloWorld). If you are converting text that matters — an API contract, a config key, a file name — keep a copy of the source before you overwrite anything.

Acronyms Come Out as Title Case

XMLParser becomes xmlParser, not xMLParser. This is intentional and matches the most common style guides (including Google's), which say acronyms inside identifiers are written in title case. If your team instead keeps acronyms fully uppercase in camelCase (XMLParser), that is a stylistic choice the tool does not automate — adjust the output by hand in that case.

Empty and Separator-Only Input

Pasting only separators (like ---) or whitespace produces empty outputs — there are no words to convert. That is expected behavior, not a bug.

Whole Files and Bulk Names

The tool converts whatever you paste, so it works equally well for a single identifier and for a whole block of names — newlines are treated as separators, so a list pasted one name per line converts cleanly as one batch. That makes it handy for renaming a set of database columns, CSS classes, or environment variables consistently: paste the whole list, copy the converted block, and paste it back over the original. For file renames on disk, convert each name here first, then use your operating system's batch-rename feature with the converted values — a quick way to keep dozens of assets in one style without retyping any of them.

Frequently Asked Questions