Case Converter
Naming conventions are arbitrary and non-negotiable: each language community picked one, and code that ignores it reads as foreign. Converting between them by hand is tedious and error-prone, particularly across a whole file.
How to use it
- Paste your text or identifier.
- Every supported case form is produced at once.
- Copy the one you need.
Which convention goes where
The conventions are not interchangeable, and using the wrong one is the fastest way to make code look like it was written by someone unfamiliar with the ecosystem.
- camelCase: variables and functions in JavaScript, Java, C#, and Swift. Also standard for JSON keys in APIs written by JavaScript teams.
- PascalCase: classes and types nearly everywhere, plus React component names, where the capital letter is functionally significant because JSX uses it to distinguish a component from an HTML element.
- snake_case: variables and functions in Python, Ruby, and Rust, plus SQL identifiers and, by convention, JSON keys in APIs written by Python teams.
- kebab-case: URLs, CSS class names and custom properties, HTML attributes, and npm package names. It cannot be used for identifiers in most languages because the hyphen parses as subtraction.
- CONSTANT_CASE: compile-time constants and environment variables, which are conventionally uppercase across essentially every platform.
Acronyms are genuinely ambiguous
There is no correct answer for how an acronym should appear in camelCase, and major codebases disagree.
Should an XML HTTP request be XMLHttpRequest or XmlHttpRequest? The browser API chose the first, and it is widely regarded as a mistake, because consecutive capitals make word boundaries unreadable: HTTPSURLParser could be parsed several ways.
The Google style guides for Java and TypeScript both mandate treating an acronym as an ordinary word, giving XmlHttpRequest and HttpsUrlParser. That is the more defensible choice, and it is what makes automated conversion reliable, because a converter can find word boundaries.
The practical consequence for round-tripping: converting XMLHttpRequest to snake_case is ambiguous, and any answer a converter gives will be wrong for someone. If you control the naming, avoid consecutive capitals and the problem disappears.
Case conversion is locale-sensitive
The Turkish alphabet has a dotted and a dotless i as distinct letters. Uppercasing a lowercase dotted i in a Turkish locale gives the dotted capital, not the ASCII I.
This has caused real production failures. Code that uppercases a string before comparing it against a literal such as ID or FILE breaks under a Turkish locale, because the uppercased i is no longer the character the literal contains. The failure only appears for users in that locale, which makes it hard to reproduce and easy to dismiss.
The fix is to use locale-invariant casing when comparing identifiers, protocol tokens, or anything else that is not human-facing text: toUpperCase with an explicit invariant locale in .NET, or comparing without case folding at all. Reserve locale-aware casing for text you are displaying to a person.
Converting across an API boundary
A Python backend using snake_case talking to a JavaScript frontend using camelCase has to convert somewhere, and picking the wrong place causes lasting pain.
Doing it ad hoc at each call site guarantees inconsistency. The workable options are converting once in the serialisation layer, so the API speaks one convention regardless of what the backend uses internally, or converting once in the frontend API client, so the rest of the frontend never sees the backend convention.
Whichever you pick, the conversion must be lossless and round-trippable, which means avoiding keys that contain digits adjacent to letters or consecutive capitals, both of which produce ambiguous word boundaries. A key like user2FAEnabled will not survive a round trip intact.
At a glance
| Forms produced | camelCase, PascalCase, snake_case, kebab-case, CONSTANT_CASE |
|---|---|
| Acronym handling | Consecutive capitals treated as one word |
| Locale | Invariant casing, not locale-aware |
| Transmitted | Nothing |
Frequently asked questions
How are acronyms handled?
A run of consecutive capitals is treated as a single word, so XMLHttpRequest becomes xml_http_request. There is no universally correct answer here, and major style guides disagree.
Why can I not use kebab-case for variable names?
The hyphen parses as the subtraction operator in most languages. It is fine in URLs, CSS, HTML attributes, and package names, where no expression parser is involved.
What is the Turkish i problem?
Turkish has dotted and dotless i as separate letters, so uppercasing i under a Turkish locale does not produce ASCII I. Code that uppercases identifiers before comparison breaks for those users. Use locale-invariant casing for non-display text.
Will converting back give me the original?
Usually, but not always. Consecutive capitals and digits adjacent to letters produce ambiguous word boundaries, so a key like user2FAEnabled may not survive a round trip.
Read more
Working with text — Diffs cannot see movement, regular expressions cannot count, and case conversion is not locale-independent.