Identifier Case Converter

What is identifier case?

Identifier case is the convention a programmer uses to join several words into one name. JavaScript and Java favour camelCase, Python and Rust use snake_case, CSS classes and URLs use kebab-case, type names are usually PascalCase, and constants are conventionally SCREAMING_SNAKE_CASE. They all encode the same words; only the joining differs.

This page detects which convention a name is already in, converts it to every other one, and tells you the one thing most converters do not: whether the conversion loses information you cannot get back.

It is the developer counterpart to this site's case converter, which handles prose — sentence case, title case and the capitalisation rules of English. Nothing here is about grammar.

How to use it

1. Paste or type any identifier. It recognises camelCase, PascalCase, snake_case, kebab-case, SCREAMING_SNAKE_CASE, Train-Case and dot.case. A string that fits none of them is reported as unrecognised rather than forced into the nearest guess.
2. Read the split. Every conversion is the same two steps — break the name into words, then join them differently — so the word list tells you exactly what the tool thinks your name says. If the split is wrong, every conversion below it will be too.
3. Copy whichever form you need. Each row has its own copy button, and the row matching your input is marked. Underneath, a note says whether converting away and back would return the name you started with.

Two libraries, two answers, and the cause is digits

Before writing this we took two widely used case libraries — one a dedicated case package, the other the case functions from a general-purpose utility library — and ran them over every camelCase and PascalCase identifier declared in this site's own source: 5,159 names. They disagreed on 71 of them, about 1.38%.

Every single disagreement was a digit. One library keeps a digit attached to the letters before it, so Base64Tool becomes base64_tool; the other treats the digit as its own word and produces base_64_tool. Same for utf8Bytes, rot13, mulberry32 and byAlpha2. We classified all 71 and the residue was zero — there was no second cause hiding behind the first.

Neither is wrong. There is no standard for this, and the two readings correspond to two reasonable views of what a digit is: part of a word like the 64 in Base64, or a separate token like a version number. This tool keeps digits attached, so Base64 stays one word, and it is worth knowing that a colleague's tool may not.

The practical consequence is small but sharp: if you generate a database column name from a class name with one tool and query it from code that uses another, base64_tool and base_64_tool will not match and nothing will tell you why.

What the conversion destroys, and how often

The famous failure is acronyms. XMLHttpRequest converts to xml_http_request, and converting back gives XmlHttpRequest — the three capitals are gone and nothing in the snake_case form records that they were ever there. The same happens to parseURL, IOError and APIKey. It is not a bug in any particular library; the information is genuinely absent from the intermediate form.

What is worth adding, because almost nobody does, is how often that actually bites. Over the same 5,159 identifiers, only four contained two or more consecutive capitals — under a tenth of one per cent — and all four survived a round trip anyway. In this codebase, the lossy case never once occurred in practice.

That is one corpus and it is a TypeScript one, where names like getElementById are the norm. A Java or C# codebase full of HTTPSConnection and XMLParser would fare very differently, and we are not claiming otherwise. But the folklore has this backwards: the conversion is described as unreliable when the honest version is that it is lossy in a narrow, identifiable case that is rare in modern naming.

There is a second half worth knowing. Once a name is in snake_case, it is stable — converting it again changes nothing, and camelCase derived from it is the same however many times you go round. The loss happens once, on the way in, and never again. So the rule is simple: convert from your original as often as you like, but do not treat a converted name as a source you can restore from.

Honest limits

The word split is the whole engine, and it makes two choices this page states rather than hides. Digits stay attached to the letters before them. And a run of capitals followed by a capitalised word splits before the last capital, so HTTPServer gives http and server rather than shattering into single letters — which is what the tool would do without that rule, and is one of the sabotage cases in the test suite.

Detection is deliberately strict. Something like mixed_Snake-kebab satisfies no convention, so it is reported as unrecognised rather than assigned to the closest one. A detector that always guesses would look more capable and tell you less.

One genuine ambiguity has no right answer. A single lowercase word — total, name, value — is both valid camelCase and valid snake_case with one word. The tool calls it camelCase, because for an identifier that is the commoner reading, but it is a convention rather than a fact.

Finally, this handles ASCII identifiers. Most languages allow letters beyond A–Z in names, and the capital-run rules here are written for the Latin alphabet. A name in Greek or Cyrillic will be split on separators but not on case boundaries.

Why is it free?

Because it is a regular expression and a join. Everything runs in your browser, nothing you type is uploaded, and there is no server involved in renaming a variable.

So there is no account, no sign-up and nothing held back. The engine and its test suite are in the repository beside the page, and the suite checks its claims against this site's own 5,000-plus identifiers rather than against invented examples — the same population the figures above came from, so the article and the tests cannot drift apart.