Case Converter — Free Online Tool on Toolpile
Every tool you need, one place
PDF, Image, AI, Dev, and Business tools — free, private, no signup.
Toolpile uses cookies for analytics and ads. The tools themselves keep your files in the browser — that doesn't change. Read the full policy
PDF, Image, AI, Dev, and Business tools — free, private, no signup.
About Case Converter
Converting text between cases — UPPERCASE, lowercase, Title Case, camelCase, snake_case, kebab-case — is one of those operations every developer does dozens of times a week, usually by typing it manually or running a one-line shell command. The interesting part isn't the conversion; it's the cases themselves. Each one signals what kind of code or content you're writing, and using the wrong case in a codebase reads as carelessness. Here's the map.
The standard cases, in roughly the order you'll encounter them in a codebase or content workflow:
Case conventions emerged because programming languages need to distinguish identifiers from each other and from natural-language content. Python picked snake_case because spaces are illegal in identifiers and snake reads as space-separated words. JavaScript picked camelCase because Java did first, and Java picked it because C didn't have a strong identifier convention so the early Java team chose visual word-boundary markers without underscores.
PascalCase (the same as camelCase but starting with a capital) emerged in C# and .NET to distinguish types from variables — `string firstName` (variable, camelCase) vs `class Person` (type, PascalCase). Most modern languages adopted this distinction; Python is the holdout (PEP 8 says snake_case for variables AND functions, but PascalCase for classes — same rule, different mechanism).
kebab-case dominates URLs because hyphens are URL-safe and Google explicitly recommends them over underscores (Google parses `bake-bread` as two words, `bake_bread` as one). CSS adopted kebab-case for class names early because hyphens were already its property-name convention (`background-color`, not `backgroundColor`).
The rule of thumb in 2026: match the convention of whatever you're writing into. Python codebase? snake_case. JavaScript object? camelCase. CSS class? kebab-case. URL slug? kebab-case. Code review comment about a variable? Use the variable's actual case. Mixing conventions in a single codebase is the most common case-related bug — `firstName` in JS files but `first_name` in JSON responses from the same API gets caught by linters but slips through manual review.
**Acronyms in camelCase**. Should `XMLHttpRequest` keep all-caps or become `XmlHttpRequest`? Different style guides disagree. Java SDK uses `XMLHttpRequest` (preserve acronyms); Microsoft's .NET style guide says `XmlHttpRequest` (only capitalise the first letter of acronyms longer than 2 chars). Most converters default to one or the other and produce something most teams accept; for codebases with strict style guides, manual review of the acronym output is unavoidable.
**Numbers in identifiers**. `bmiCalc2` vs `BmiCalc2` vs `bmi_calc_2` — converters split words at lowercase→uppercase transitions, but numbers can fit either side. `bmiCalc2` → snake_case is `bmi_calc_2` (split before number) or `bmi_calc2` (number stays attached). Most tools follow the convention of the destination case; this one does the same.
**Single-letter prefixes**. `iCare` (camelCase, hi single-letter `i`) → `i_care` (snake) or `icare` (joined). Apple's HIG-influenced naming has lots of these (`iPhone`, `iCloud` — though those are brand names, not identifiers). The general rule: treat single capitals as new words unless followed by a single lowercase (in which case they're acronyms or brand names).
**Non-ASCII characters**. `cafétéria` → snake_case. Stripping the accent gives `cafeteria`; preserving it gives `cafétéria`. SEO-aimed slug conversion strips accents; identifier-aimed conversion (Python 3 allows non-ASCII identifiers) preserves them. Pick based on the destination — slug → strip; variable name → preserve if the language allows it.
Should I use camelCase or snake_case for my variable names?
Match the language and codebase. Python and Ruby strongly prefer snake_case (PEP 8 for Python is widely-followed). JavaScript and TypeScript use camelCase by community convention. C# and Swift use camelCase for variables, PascalCase for types. Within a single codebase, consistency matters more than which one — picking the language's idiomatic convention saves arguments.
Is Title Case the same in every English style guide?
No. APA, Chicago, MLA, and AP each have slightly different rules about which words to capitalise. Most converters use a simplified "capitalise major words, lowercase a/an/the/of/in/on/at/to/for" rule that's close to APA. For published-content title case, check your style guide — academic submissions especially. For UI buttons and headings, use sentence case instead (modern Google/Apple guidance) and avoid the debate.
What about UPPER_SNAKE_CASE vs SCREAMING_SNAKE_CASE — same thing?
Same thing. Both names refer to all-uppercase + underscore-separated. Used for constants in most languages (`MAX_RETRY_COUNT`, `API_BASE_URL`) and environment variables in shell (`DATABASE_URL`, `NODE_ENV`). "SCREAMING" is the more colourful name; "UPPER_SNAKE_CASE" is the more searchable one.
How do I convert mixed-case input correctly?
Tell the converter how to split words. Most converters detect word boundaries from existing transitions (camelCase has hidden boundaries at lowercase→uppercase; snake_case has explicit underscores). For input like `XMLHttpRequest` or `iPhone`, the boundary detection picks one interpretation — hand-check if the result is wrong and adjust manually.
Why doesn't this convert properly handle Unicode?
Modern converters (this one included) handle the basic Latin extended set — accented characters convert their case correctly (`É → é`, `Ñ → ñ`). For more exotic scripts (Greek, Cyrillic, Arabic case-mapping), JavaScript's built-in `toLowerCase`/`toUpperCase` follow Unicode rules and work correctly. Edge cases in Turkish (`I` and `i` are different from the Latin `I` and `i` due to dotted/dotless distinction) require locale-aware conversion (`toLocaleLowerCase('tr')`); generic converters get this wrong about 5% of the time on Turkish input.