Case Converter

Case Converter - Text Case Transformation Tool

Case transformation looks like a one-line string operation until you ask what is actually correct. Pure ASCII (A-Z, a-z) is uncontroversial — every byte has an obvious mate. But the moment your text contains accented Latin (é, ñ, ç), Greek (Σ, ς, σ), Cyrillic (д, Д), German ß, Turkish dotted-i (i ↔ İ, ı ↔ I), or scripts with no case at all (Arabic, Chinese, Japanese, Korean, Thai, Devanagari), the rule book multiplies. This converter uses JavaScript's Unicode-aware toUpperCase and toLowerCase, which correctly handles single-codepoint case folding for almost every modern script while leaving emoji, digits, punctuation, and uncased characters untouched byte-for-byte. Title Case here applies the simple Start Case rule (capitalize every word) — editorial style guides (AP, Chicago, APA, MLA) lowercase short function words like "of", "the", "and" with conflicting cutoffs, so manual editorial polish remains your job. Sentence case detects boundaries by terminal punctuation (. ? !) followed by whitespace, which may misfire on abbreviations like "Dr. Smith" or "e.g. this" — review the output for those. All processing is local to your browser; the text never leaves your device, suitable for confidential drafts under NDA. See also our Character Counter and the Markdown to HTML.

How do I convert text to camelCase, snake_case, or kebab-case programmatically?

Standard four cases (lowercase, UPPERCASE, Title Case, Sentence case) cover most prose needs, but developers often want programmer cases. camelCase joins words with no separator and lowercases the first letter (myVariableName); PascalCase capitalizes the first too (MyClassName); snake_case uses lowercase with underscores (my_variable_name); kebab-case uses lowercase with hyphens (my-css-class). To produce these from arbitrary text, first split on any non-alphanumeric run and on uppercase boundaries, lowercase each token, then rejoin with the chosen separator. This tool focuses on natural-language cases because programmer cases require explicit tokenization that can lose information (was "iOS" one acronym or three letters?). For code identifiers, prefer your IDE's refactor tools, which understand language-specific reserved-word rules.

Why does Title Case give different results than I expect for short words like 'of', 'and', 'the'?

Pure Title Case (sometimes called Start Case) capitalizes every word, which is what this tool does by default: "The Lord Of The Rings." But editorial Title Case follows style guides (AP, APA, Chicago, MLA) that lowercase short function words like articles (a, an, the), short prepositions (of, in, on, at, to, for, by), and coordinating conjunctions (and, but, or, nor, for, yet, so) unless they start the title. So Chicago would render "The Lord of the Rings." The exact list varies by style: APA lowercases prepositions under four letters, Chicago under five. Because there is no single "correct" rule, this converter applies the simpler universal capitalize-every-word rule and leaves editorial polishing to you.

Does case conversion work correctly for accented characters and non-Latin scripts?

Modern JavaScript uses Unicode-aware toLowerCase() and toUpperCase(), so accented Latin (é → É, ñ → Ñ), Cyrillic (д → Д), and Greek (α → Α) convert correctly. But several scripts have no case at all — Arabic, Hebrew, Chinese, Japanese, Korean, Thai, Devanagari — and those characters pass through unchanged. Some pairs are also language-dependent: Turkish dotted-i (i ↔ İ) and dotless-ı (ı ↔ I) require locale-aware toLocaleLowerCase('tr-TR') to produce correct results, and German ß traditionally upper-cases to SS but Unicode 5.1 added a capital ẞ. This converter uses the default locale, which is fine for English, Spanish, French, Portuguese, and Vietnamese; for Turkish content, do a manual locale-aware pass.

What happens to whitespace, punctuation, and emoji during case conversion?

Case conversion only touches characters that have a defined case mapping. Digits (0-9), punctuation (.,!?;:), brackets and quotes, mathematical symbols, currency signs, whitespace (spaces, tabs, newlines), and emoji all pass through byte-for-byte unchanged. So "Hello, World! 😀" lowercased becomes "hello, world! 😀" and uppercased becomes "HELLO, WORLD! 😀." Sentence case detects sentence boundaries by looking for terminal punctuation (. ? !) followed by whitespace, then capitalizes the next letter — abbreviations like "Dr. smith" or "e.g. this" may incorrectly trigger a new "sentence," so review the output. Title Case detects word boundaries via whitespace and hyphens, so hyphenated compounds become "Well-Known," not "Well-known."

How does case affect text encoding size and storage in UTF-8?

For pure ASCII (English letters A-Z, a-z), uppercase and lowercase both occupy exactly one byte per character in UTF-8, so case conversion never changes file size. For accented Latin (à, é, ñ), each character is two bytes in UTF-8 regardless of case, so converting between é and É is byte-equivalent. However, a few special characters change byte count when cased: the German ß is two bytes, but capitalizing it to "SS" produces two ASCII bytes — net zero. The Unicode capital sharp S ẞ (U+1E9E) is three bytes. The Greek final sigma ς (two bytes) upper-cases to Σ (two bytes), but lowercasing Σ gives σ or ς depending on word position. Net: case rarely changes UTF-8 size by more than a fraction of a percent.

What is the difference between visual capitalization and "true" uppercase in CSS vs. text?

CSS provides text-transform: uppercase, lowercase, and capitalize as a presentation layer — the underlying HTML text is unchanged, only the rendered display is transformed. This is useful for headings and navigation labels because you can later restyle without editing content. However, CSS uppercase is screen-reader-friendly only if the original text is grammatically correct; an acronym typed as "nasa" rendered uppercase via CSS still reads as the lowercase word to assistive tech. True text-level uppercase (what this tool produces) changes the actual characters in the document, so copy-paste, search, and SEO see the new form. Rule of thumb: use CSS text-transform for purely stylistic capitalization that may change with redesign; use this tool when the canonical content itself should be in a particular case.

How do I detect and normalize mixed-case text from scraped or user-generated content?

Web-scraped text often contains a chaotic mix: SHOUTING CAPS in reviews, "sTuDiO gIbBlI" mocking case, all-lowercase Twitter posts, and inconsistent product names. The cleanup pipeline is: (1) detect dominant case using heuristics — if 80%+ of letters are uppercase, treat as shouting and lowercase; (2) tokenize into words; (3) preserve known acronyms (NASA, USA, HTML) by checking against a whitelist; (4) apply Title Case to proper-noun-like fragments (capital after lowercase in original); (5) apply Sentence case otherwise. For Vietnamese, Portuguese, and Spanish, also normalize Unicode (NFC) so combined characters like é (one codepoint) and e + combining acute (two codepoints) compare equal. This converter handles steps 2-5; preprocessing for detection is best done in a script before pasting.

Why do search engines and LLM tokenizers treat uppercase and lowercase as different tokens?

Search engines like Google normalize most text to lowercase during indexing, so "Apple" and "apple" return the same results in everyday queries — case-folding is part of the analysis pipeline. But subword tokenizers used by large language models (BPE in GPT family, WordPiece in BERT) treat "Apple," "apple," and "APPLE" as completely different tokens during training because the model needs to learn that capitalization carries meaning (proper noun vs. fruit vs. shouting). This is why prompt engineers see different completions for "write about Python" vs. "write about python" — the first leans toward the programming language, the second toward the snake. For SEO content, casing barely affects rankings; for LLM prompting, consistent canonical casing improves reproducibility and reduces token waste.

Case Conversion Examples