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 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.

Developer Implementation Guide: Programmatic Case Conversion

Converting case in code is surprisingly difficult due to edge cases like consecutive capital letters (e.g., XMLHTTPRequest). Below is a robust JavaScript implementation for converting strings to camelCase.

Robust camelCase Function

This function handles spaces, underscores, and hyphens, safely converting them into camelCase.

function toCamelCase(str) {
  return str
    // Replace dashes and underscores with spaces
    .replace(/[-_]+/g, ' ')
    // Replace non-alphanumeric characters with spaces
    .replace(/[^\w\s]/gi, '')
    // Split into words, capitalize the first letter of each word (except the first)
    .replace(/\s+(.)/g, function(match, group1) {
      return group1.toUpperCase();
    })
    // Ensure the very first character is lowercase
    .replace(/^(.)/, function(match, group1) {
      return group1.toLowerCase();
    })
    // Remove remaining spaces
    .replace(/\s+/g, '');
}

console.log(toCamelCase("user_first_name")); // "userFirstName"
console.log(toCamelCase("hello-world")); // "helloWorld"
        

For large-scale structural changes (like converting entire database schemas or API responses), consider using dedicated libraries like lodash/camelCase which have been battle-tested against thousands of edge cases.