Case Converter

How to use this case converter

1. Type or paste any text into the box above.
2. All 9 case formats generate instantly below.
3. Click "Copy" next to the format you need.

When do I need each case format?

camelCase and PascalCase are standard for variable and class names in JavaScript, Java and C#. snake_case is common in Python and databases. kebab-case is standard for URLs and CSS classes. CONSTANT_CASE is typically reserved for constants and environment variables.

Why detecting word boundaries correctly is genuinely harder than it looks

Converting between case formats depends entirely on first correctly identifying where one "word" ends and the next begins within the input text, and this word-boundary detection is a genuinely trickier problem than it might initially seem. Simple cases are straightforward — spaces, hyphens, and underscores are unambiguous, explicit separators. But camelCase and PascalCase input specifically require detecting boundaries purely from capitalization changes instead, and this gets genuinely ambiguous fast with consecutive capital letters, like in "XMLHttpRequest" or "iOSApp" — should "XML" be treated as one single word, or as three separate single-letter words (X, M, L)? Different case-conversion tools and libraries genuinely handle this specific ambiguous scenario differently, which is exactly why converting an identifier containing an acronym or initialism between formats can occasionally produce a result that looks visually different from what a human would have intuitively, manually chosen to write themselves.

Why different programming languages settled on genuinely different naming conventions

The specific case convention a language community adopts is largely a matter of established historical convention and, importantly, of official style guides that were deliberately codified and then widely, consistently followed, rather than any actual technical requirement of the language itself. Python's official PEP 8 style guide specifically recommends snake_case for variable and function names, which is exactly why that convention became so dominant and consistent throughout the Python ecosystem specifically. JavaScript and Java both converged on camelCase for variables and functions, with PascalCase reserved specifically for class names, following their own separate community conventions and official style guide traditions. None of these specific conventions are enforced by the actual language's own compiler or interpreter — using snake_case in JavaScript, for instance, runs completely without any technical error at all — but deliberately following each specific language ecosystem's own established convention makes code immediately, instantly more readable and familiar to other developers already working within that same specific ecosystem and its shared expectations.

The real, nuanced rules behind proper Title Case — it's not simply "capitalize every word"

True, formally correct Title Case, as used in professional publishing and formal editorial style guides (AP Style, Chicago Manual of Style, and similar), is genuinely more nuanced than the simplified "capitalize every single word" version this tool and most casual tools implement for everyday convenience. Formal, professional style guides specifically call for lowercasing short, minor words — articles (a, an, the), coordinating conjunctions (and, but, or), and short prepositions (of, in, on) — unless that specific word happens to be the very first or very last word of the title, in which case it's still capitalized regardless of its own type. Under those stricter, more formal rules, "The Lord of the Rings" correctly keeps "of" and the second "the" lowercase, while a simplified "capitalize everything" tool like this one would instead produce "The Lord Of The Rings" instead. This distinction matters specifically for formal writing and professional publishing contexts, though the simpler, everyday "every word capitalized" convention remains genuinely common and widely accepted for casual, informal, everyday use.

Why converting back and forth between formats can genuinely lose information

Case conversion isn't always perfectly, cleanly reversible round-trip in both directions, and it's worth understanding specifically why. Converting "XMLParser" (PascalCase, with the acronym preserved as fully uppercase) to snake_case might produce "xml_parser," which is sensible and reasonable — but converting that same "xml_parser" back to PascalCase afterward would typically produce "XmlParser" rather than the original "XMLParser," since the specific information about which particular letters originally formed a meaningful, intentional acronym gets genuinely lost once everything gets lowercased during the snake_case conversion step. This is a real, structural limitation inherent to case conversion generally, not something unique to any one particular tool or implementation — once the original capitalization pattern that specifically distinguished an acronym from an ordinary regular word gets flattened during an intermediate conversion step, that specific distinction generally can't be automatically, reliably recovered afterward without additional external context a conversion tool simply doesn't have access to.

Limitations of this tool

This tool splits input text on spaces, hyphens, underscores, and capitalization changes to detect word boundaries, then reassembles those detected words into all 9 supported case formats — as explained above, this word-boundary detection can be genuinely ambiguous for text containing acronyms or consecutive capital letters, and as the FAQ notes, accented characters are preserved as-is rather than being specially normalized during conversion. This tool's Title Case implementation capitalizes every single word for everyday simplicity and convenience, rather than implementing the more nuanced small-word-lowercasing rules formal editorial style guides like AP or Chicago style specifically require, as explained in more detail above.