Changing the case of text sounds like the most trivial operation a computer performs. It is not, and the ways it goes wrong have broken real software. This tool converts between ten conventions at once — but a few of those conversions throw information away permanently, and it is worth knowing which.
Uppercasing is a one-way door
Most people assume case conversion is reversible. It is not. The German ß has no uppercase form of its own, so uppercasing turns it into two letters: straße becomes STRASSE. One character became two.
Now go back. STRASSE lowercased is strasse — with ss, not ß. The original letter is gone and nothing can recover it, because by the time you lowercase, there is no record that those two S characters used to be one ß. Round-tripping a German word through uppercase silently changes its spelling.
The ligature fi does the same thing, becoming FI. This is why a database column that stores an uppercased copy of a name for searching quietly loses information, and why comparing text by uppercasing both sides is a subtly worse idea than it looks.
The Turkish I, which has broken production systems
Turkish has two letter I: a dotted one and a dotless one, and they are different letters with different meanings. Uppercase dotted i is İ. Lowercase dotless I is ı.
This collides with a habit every developer has. In JavaScript, "title".toUpperCase() gives TITLE. But "title".toLocaleUpperCase("tr") gives TİTLE — with a dot on the I. If a user has a Turkish locale and your code uppercases a string to compare it against a constant, the comparison fails, and it fails only for Turkish users. The same applies in reverse: "I".toLocaleLowerCase("tr") is ı, not i.
This has taken down real software, repeatedly. The rule that avoids it is that case conversion for comparison should be locale-independent, while case conversion for display should follow the user's locale. They are different operations that happen to share a name. This tool converts for display and does not pretend to be a comparison function.
Acronyms survive one direction and not the other
Splitting a camelCase identifier into words is more delicate than it looks, because a run of capitals might be an acronym. A naive split on every capital turns parseHTMLDocument into parse_h_t_m_l_document, which is nonsense.
This tool handles it: parseHTMLDocument becomes parse_html_document, XMLHttpRequest becomes xml_http_request, getUserID becomes get_user_id. It looks for the boundary where a run of capitals meets a capital followed by lowercase, which is where the acronym ends and the next word starts.
The return journey cannot work, and this is worth understanding rather than reporting as a bug. Convert parse_html_document back to camelCase and you get parseHtmlDocument, not parseHTMLDocument. The snake_case form never recorded that html was an acronym — that information was destroyed on the way out, and no amount of cleverness on the way back can invent it. If you are converting identifiers in a codebase, convert once and review, rather than round-tripping and trusting.
Title Case is not a defined operation
Ask two style guides to title-case the same sentence and you will get two answers. AP style capitalises words of four letters or more. Chicago capitalises everything except articles, coordinating conjunctions and short prepositions — unless they are the first or last word. Neither says "capitalise every word".
That is what this tool does, because it is the only rule that works without knowing your style guide, your language, or which words are proper nouns. It is a reasonable default and it is not real title case: "The Lord Of The Rings" is what you get, and Chicago would tell you it is "The Lord of the Rings". For headlines that matter, use the output as a starting point and fix the small words by hand.
Common questions
Is my text sent to a server?
No. This tool is marked "client": every conversion runs in your browser tab and nothing is transmitted.
Which case should I use for what?
Follow the language, not your preference — every ecosystem has a convention and fighting it makes your code look foreign. camelCase for JavaScript and Java variables, PascalCase for classes and components, snake_case for Python and database columns, kebab-case for URLs and CSS, CONSTANT_CASE for constants and environment variables. The one place to think rather than follow is URLs, where kebab-case is not just convention: underscores are harder to see under a link's underline.
Why did my German word change spelling?
You uppercased a ß. It became SS, and lowercasing brought back ss rather than ß, because the information was lost in the first step. This is not this tool being careless — it is what Unicode specifies, and every correct implementation does the same. If you need the original, keep the original; do not reconstruct it from an uppercased copy.
Is uppercase safe for comparing two strings?
Not reliably. Beyond the Turkish problem above, there are characters whose uppercase and lowercase forms do not round-trip, so two strings can uppercase to the same thing while being genuinely different, and vice versa. For comparison, use a locale-independent case fold — in JavaScript, localeCompare with sensitivity set to "base" or "accent" is usually what you actually want.
Why does my sentence case look wrong on names?
Because sentence case lowercases everything after the first character, and it has no way of knowing that Paris is a place. "john went to paris" is what you get from "JOHN WENT TO PARIS". Recovering proper nouns needs a dictionary and, for ambiguous cases, a human. If your text was shouted at you in all caps, sentence case gets you most of the way and the names need a pass by eye.