Case Style Converter

What this tool is used for

• Converting an identifier between the conventions two languages use.
• Normalising a list of field names to one style.
• Converting a whole list of identifiers between two languages' conventions at once.
• Converting API keys from snake_case to camelCase for a client.
• Checking how a multi-word name splits before converting it.

Frequently Asked Questions

How does it know where the words are?

It splits on camelCase boundaries first, while the original capitalisation is still there, then folds separators to spaces, then drops leftover punctuation. Order matters: doing it the other way round loses the boundary information, which is how helloWorld ends up as helloworld instead of hello_world.

What happens to acronyms like HTMLParser?

They split correctly, into HTML and Parser. The rule looks for a run of capitals followed by a capital-then-lowercase, which is the boundary a naive camelCase splitter misses — it would otherwise produce h_t_m_l_parser, one word per letter.

Are accented and non-Latin identifiers safe?

Yes. Splitting is Unicode-aware, so café stays café rather than becoming caf, and combining marks are preserved — a decomposed e followed by U+0301 keeps its accent instead of losing it. Many case converters delete anything outside ASCII, which silently destroys data.

Which convention should I use where?

Follow the language, not preference: camelCase for JavaScript and Java variables, PascalCase for classes and React components, snake_case for Python and SQL, kebab-case for URLs, CSS custom properties and HTML attributes, and CONSTANT_CASE for environment variables and compile-time constants.

Why is kebab-case wrong for a variable name?

Because a hyphen is the subtraction operator in almost every language, so first-name parses as first minus name. That is precisely why it is safe in CSS and URLs, where no arithmetic is being parsed, and unusable in code identifiers.

How should an acronym be handled in camelCase?

Inconsistently in the wild, which is the problem — `parseHTTPResponse` and `parseHttpResponse` are both common. Treating an acronym as an ordinary word is the more mechanical rule and survives round-tripping.

Common errors and gotchas

• Mangling acronyms, where `HTTPResponse` becomes `h_t_t_p_response` rather than `http_response`.
• Losing a digit boundary, where `v2Api` splits differently depending on the implementation.
• Converting a value that is compared exactly somewhere downstream.
• Assuming the conversion round-trips, which it does not once an acronym is involved.
• Converting a name containing a language-specific character, where casing rules differ by locale.