Case Converter

A case converter has exactly one hard part, and it is not the casing. It is deciding where one word ends and the next begins in XMLHttpRequest, iso8601Date or Größe. Get that split right once and camelCase, snake_case, kebab-case and the other ten are just different ways of gluing the words back together. Most converters get it wrong in the same three places, and those three are the ones this page spends its time on.

The thirteen cases

The names are folklore rather than standard, so two people can mean different things by "camel case". This is what the cards above produce, for the input XMLHttpRequest parser with the default options.

Two of those rows deserve a second look. Title Case and Sentence case treat a line that contains spaces as text, not as an identifier. Punctuation stays where it was, all-caps words such as HTTP are left alone, and a word with a capital inside it (XMLHttpRequest, iPhone, macOS) is not lowercased, because every mechanical rule that touches it produces Iphone. An identifier without spaces is split into words first, so user_id still becomes User Id. lowercase and UPPERCASE are the only two that do not split at all. They recase the line and leave every separator as it was, which is what you want for API_KEY and not what you want for apiKey.

COBOL-CASE, the hyphenated capitals, is missing on purpose. Outside COBOL nobody types it, and it would only push a useful card below the fold.

How the converter works

Paste identifiers or text, one per line, and every case appears at once. A whole column of database fields or an entire API response shape is the better use. The "a whole API" preset takes six camelCase keys to snake_case in one paste. Under the input, each line says what it looks like (snake_case, Title Case, mixed separators), so an inconsistent input shows before it is converted. Clicking a card makes that case the big result with its own copy button, and "use as input" feeds a result back in, the quickest way to check that a round trip survives.

The four options each decide one of the splitting questions. --acronyms treats a run of capitals as one word, so XMLHttpRequest becomes xml_http_request and HTTP stays HTTP in Title Case, while off makes every capital start a word. --split-digits decides whether 8601 in iso8601Date is its own word. --ascii transliterates before converting, with the German two-letter spelling for umlauts and ss for ß, and drops whatever is left outside ASCII. --small-words keeps a, of, the and the other short words lowercase inside Title Case, the short words AP and Chicago both lowercase, unless the word comes first or last.

Apostrophes stay in the text cases and vanish in the identifier ones, so don't stop is Don't Stop and dontStop. A leading or trailing underscore survives in the five cases where an underscore is legal identifier syntax (_cache in camelCase, class_ in snake_case) and is dropped in kebab-case and the rest. Everything is computed in your tab as you type, which matters less for a variable name and more for the column list of a production schema.

Which convention goes where

The choice is almost never yours. Each language settled its conventions decades ago, and the ones that did not (JSON keys) are the ones that cause the arguments. URL slugs are kebab-case too, but with stop words removed and punctuation dropped, which is a job for the slug generator rather than a case converter.

SQL is snake_case for a reason that has nothing to do with taste. PostgreSQL folds every unquoted identifier to lowercase and Oracle to uppercase, so createdAt becomes createdat or CREATEDAT unless it is quoted, and a quoted "createdAt" must be quoted in every query forever. Underscores survive the folding, which is why a header row on its way into CSV to SQL is worth running through the snake_case card first. Environment variables are capitals for a similar boring reason. POSIX reserves the uppercase names for the system and its utilities and leaves lowercase to applications.

Go is the odd one out twice. Case is semantics there, not style. A name starting with a capital is exported, a lowercase one is package-private, so PascalCase versus camelCase is decided by visibility and not by kind. And Go keeps acronyms in capitals, which is the next section.

userId or userID

Every style guide agrees that XMLHTTPRequest is unreadable and then disagrees about the fix. Google's Java style guide (section 5.3) says to treat an acronym as a word: XmlHttpRequest, newCustomerId, supportsIpv6OnIos. The Go code review comments say the opposite: ServeHTTP, userID, xmlHTTPRequest, never ServeHttp. Swift's API design guidelines sit with Go for the uppercase form but lowercase the whole acronym when it starts a lowerCamelCase name: URLSession as the type, utf8Bytes as the property. Microsoft's .NET guidelines split by length: two letters stay capitals (System.IO, UI), three or more become a word (XmlReader, HtmlElement), and Id is always a word.

A converter cannot know which guide you follow, but it can at least split the identifier correctly, and that is where most of them fail:

XMLHttpRequest  ->  x_m_l_http_request
userID          ->  user_i_d
getHTTPResponse ->  get_h_t_t_p_response

XMLHttpRequest  ->  xml_http_request
userID          ->  user_id
getHTTPResponse ->  get_http_response

The rule on the right is simple to state. A run of capitals is one word, and the last capital of the run starts the next word if a lowercase letter follows it. XMLHttp splits into XML and Http, userID into user and ID. The converter above does this by default, and the --acronyms toggle shows you the naive split if you need to match a tool that does it the other way. Going back into camelCase, the words are joined the Google way (userId, xmlHttpRequest), which is also what lodash and inflection produce. If your codebase is Go, that is the one place where you still edit the result by hand, and the findings row tells you so.

One consequence people hit in reverse. user_id into camelCase is userId, and converting that back to snake_case is user_id again. userID, the Go spelling, also round-trips cleanly. The naive split is the only one that does not, because user_i_d never becomes userID again.

Digits, ß and the Turkish i

Digits have no case, so every converter has to decide whether iso8601Date is two words or three. lodash says three (iso_8601_date), Python's inflection says two (iso8601_date), and a digit followed by a capital is a boundary in both (Code2Fast is code2_fast or code_2_fast, never code2fast). The --split-digits flag picks the side, and the findings row shows both readings when a line contains a digit next to a letter.

Unicode is where the ASCII-only tools quietly destroy data. A converter built on [a-z] and [A-Z] treats Größe as Gr, something, e, and either throws the umlaut away or splits on it. The engine above uses the Unicode categories (\p{Lu}, \p{Ll}, \p{N}), so Straße Größe is straße_größe, which Python 3, Java, JavaScript and PostgreSQL all accept as an identifier. Whether you want that is a separate question, and --ascii answers it the German way: strasse_groesse, with ae, oe, ue rather than the bare vowels a generic diacritic strip produces, and ł, ø, æ mapped to their conventional ASCII spellings instead of being dropped. lodash deburrs the generic way and gives strasse_grosse, so the two agree on ß and disagree on every umlaut. An identifier that looks right and still fails usually carries a character you cannot see, and that is a case for the invisible character detector, not for a case converter.

Two letters break the assumption that upper and lower case have the same length. "ß".toUpperCase() is "SS" in JavaScript, so Straße in UPPERCASE has seven characters and the round trip gives strasse, not straße. And the Turkish i: "I".toLocaleLowerCase("tr") is ı, "i".toLocaleUpperCase("tr") is İ, while the plain toLowerCase() always gives i. The converter uses the locale-independent methods on purpose, so the output does not depend on the language of whoever pastes. Code on a Turkish server with the default locale has no such luxury, which is why "TITLE".toLowerCase() in Java is a known way to break a switch on string constants.

Changing case in code and editors

The reason to know the one-liners is that case conversion belongs in a build step or a serializer, not in a browser tab, once it runs more than once.

The JavaScript regex is the one to memorise because it is the acronym-aware split from the section above in two passes: one for a lowercase letter or digit followed by a capital, one for a run of capitals followed by a capital and a lowercase letter. Digits stay glued to the word before them in this version (code2_fast). lodash 4.18 does all of this for you and adds two things you should know about before trusting it in a serializer. It deburrs, so Straße becomes strasse and Größe becomes grosse whether you wanted that or not, and it drops apostrophes, so don't becomes dont, in _.startCase as well.

In a serializer, do not write the regex at all. Jackson has PropertyNamingStrategies.SNAKE_CASE, Pydantic has alias_generator, .NET 8 has JsonNamingPolicy.SnakeCaseLower, and each applies one fixed rule to acronyms that you can test once.

The verdict, and where it is wrong

Use the convention of the language you are writing in and never mix two in one codebase.

Mechanical conversion is wrong in two places: proper nouns, which Title Case and Sentence case cannot recognise (GitHub, van der Berg, Vienna), and acronyms in Go, where userId is wrong and userID is right. Both get finished by hand.

Case questions people search for