---
title: "Text Case Converter: camelCase, snake_case, kebab-case"
description: "Free text case converter. Instantly convert text to camelCase, PascalCase, snake_case, kebab-case, Title Case, or UPPERCASE, with one-click copy."
url: https://frontendhelpers.com/text-case-converter
updated: 2026-10-12
---

# Text case converter

Convert any text between the six naming conventions developers use daily — camelCase, PascalCase, snake\_case, kebab-case, Title Case and UPPERCASE.

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

```javascript
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](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Regular_expressions/Unicode_character_class_escape).

## Frequently asked questions

### What is the difference between camelCase and PascalCase?

Both join words with capitals, but camelCase starts lowercase (getUserName) and PascalCase starts uppercase (GetUserName). JavaScript uses camelCase for variables and functions, and PascalCase for classes and React components.

### Should URLs use hyphens or underscores?

Hyphens. Google treats a hyphen as a word separator, so css-tricks reads as two words, while css\_tricks is read as one. Google has recommended hyphens in URLs for well over a decade.

### Why do databases use snake\_case?

Many SQL dialects fold unquoted identifiers to lowercase, which makes camelCase unreliable across systems — userName can silently become username. snake\_case survives that folding intact, so word boundaries stay readable.

### How does the converter handle acronyms like XMLHttpRequest?

It splits only where a lowercase letter or digit is followed by a capital, so a run of capitals stays attached to the word after it: XMLHttpRequest becomes xmlhttp and request, giving xmlhttpRequest in camelCase. Acronyms are genuinely ambiguous in case conversion — check the result when your input contains them.

## Related tools

- [URL Slug Generator](https://frontendhelpers.com/url-slug-generator): Turn headlines into clean kebab-case slugs with stop words removed.
 
- [HTML Entity Encoder](https://frontendhelpers.com/html-entity-encoder): Escape special characters safely for markup and code samples.
 
- [32 JavaScript tricks](https://frontendhelpers.com/js-tips): Modern snippets with the reasoning behind them, and runnable demos.

---

This page is a free interactive tool. Use it in your browser at https://frontendhelpers.com/text-case-converter