Text case converter

How to use this tool

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 treats spaces, hyphens, underscores and other punctuation as separators, and it detects camelCase boundaries where a lowercase letter or a digit is followed by a capital.

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.

Splitting acronyms like XMLHttpRequest correctly

Every case converter is a word splitter followed by a join. The usual one-regex splitter breaks wherever a lowercase letter meets a capital. That handles userFirstName but not runs of capitals: XMLHttpRequest comes out as xmlhttp and request, because nothing marks the boundary between XML and Http. A second rule fixes it: in a run of capitals, split before the last one when it starts a lowercase word. Writing the rules with Unicode property escapes (\p{Lu}, \p{Ll}) rather than [A-Z] also keeps accented letters, which ASCII-only splitters quietly drop.

function splitWords(input) {
  return input
    .replace(/([\p{Ll}\p{N}])(\p{Lu})/gu, '$1 $2')   // fooBar   → foo Bar
    .replace(/(\p{Lu})(\p{Lu}\p{Ll})/gu, '$1 $2')    // XMLHttp → XML Http
    .split(/[^\p{L}\p{N}]+/u)                        // spaces, - _ . etc.
    .filter(Boolean)
    .map(w => w.toLowerCase());
}

const cap = w => w[0].toUpperCase() + w.slice(1);
const toCamel = s => splitWords(s).map((w, i) => (i ? cap(w) : w)).join('');
const toSnake = s => splitWords(s).join('_');
const toKebab = s => splitWords(s).join('-');

console.log(splitWords('XMLHttpRequest'));  // [ 'xml', 'http', 'request' ]
console.log(toSnake('parseJSONResponse'));  // parse_json_response
console.log(toKebab('getHTTPSUrl'));        // get-https-url
console.log(toCamel('crème_brûlée-recipe')); // crèmeBrûléeRecipe
console.log(toCamel('XMLHttpRequest'));     // xmlHttpRequest – not the original!

Look at the last line. Splitting throws information away: once XMLHttpRequest is three lowercase words, nothing records that two of them were acronyms, so converting back gives xmlHttpRequest. Whether that is acceptable depends on your style guide. Google's JavaScript style guide treats acronyms as ordinary words (XmlHttpRequest), while the DOM mixes both styles within that one name. If particular identifiers must survive unchanged, keep an explicit exceptions map rather than making the regex cleverer.

MDN covers the \p{…} syntax, and the u flag it requires, in Unicode character class escape.