Why every layer of the stack uses a different case
The conventions aren't arbitrary — each one exists because of a constraint in its environment.
camelCase dominates JavaScript because identifiers can't contain hyphens (a hyphen is the minus operator) and the language's own APIs use it. PascalCase distinguishes things that get instantiated or rendered — classes, and components in React, where an uppercase first letter is what tells JSX to treat a tag as a component rather than an HTML element.
kebab-case owns CSS and URLs. Both are case-insensitive contexts where hyphens read naturally, and Google explicitly treats hyphens as word separators in URLs while underscores join words together. snake_case rules databases and Python, largely because many SQL dialects fold unquoted identifiers to lowercase, making camelCase unreliable across systems.
The conversion is harder than it looks
Converting between cases means first splitting text into words — and the input rarely announces its own format. This converter handles the common cases: it splits on spaces, hyphens and underscores, and it detects camelCase boundaries by looking for a lowercase character followed by an uppercase one.
The edge cases that break naive converters are worth knowing if you write your own. Consecutive capitals (XMLHttpRequest, parseJSON) are genuinely ambiguous — is JSON one word or four letters? Numbers create similar problems: should address2 become address-2 or address2? There is no universally correct answer, only a convention your codebase applies consistently.
Where conversion actually comes up
The most frequent real-world case is crossing a boundary between systems. An API returns snake_case JSON and your JavaScript wants camelCase. A design token named in kebab-case needs a camelCase equivalent in a theme object. A database column becomes a form field name.
For one-off work a converter is faster than fiddling with a regex. For anything systematic, do the conversion in one place — a single mapping layer where API responses enter your app — rather than scattering ad-hoc renames through your codebase.
Consistency beats correctness
There is no objectively best convention, and arguing about it is one of programming's great time sinks. What genuinely costs teams time is inconsistency: when developers have to guess whether a helper is getUserId, get_user_id or GetUserID, every lookup becomes a search.
Pick a convention per layer, follow the ecosystem's default where one exists, write it down, and enforce it with a linter so it stops being a discussion. If you need to rename existing code, do it as its own commit — mixing renames into a feature change makes the diff unreviewable.