Paste any text and get it back in every common programming case, plus a URL slug.
Type or paste text to convert it.
When to use each case
Naming conventions are mostly about matching the language you are writing in. JavaScript and Java use camelCase for variables and PascalCase for classes and components. Python and Rust use snake_case for variables and functions. CSS classes, file names and URLs use kebab-case. CONSTANT_CASE marks values that never change.
The URL slug output goes further than kebab-case: it also strips accents and punctuation, so "Zażółć gęślą jaźń!" becomes a clean, safe address segment. That makes it the right choice for page URLs, file names and anchor links.
Uppercasing straße gives you a longer string, and lowercasing it back gives a different word
Changing case looks like a character-for-character swap. It is not. German ß uppercases to SS, so a six-character word becomes seven — and lowercasing the result gives strasse, which is not the word you started with. Case conversion can change length, is not reversible, and depends on the reader's language.
How it works
- Converts between upper, lower, title, sentence, camel, snake and kebab case.
- Uses locale-aware conversion, because the correct result differs by language.
- Handles characters whose case change alters the length of the string.
uppercase and lowercase are NOT inverse operations straße → STRASSE → strasse (6 → 7 → 7 characters) locale matters: "I".toLowerCase() → "i" Turkish locale → "ı" (U+0131, dotless)
Worked example
Two cases where the naive conversion is wrong.
- straße is 6 characters
- uppercased → STRASSE, 7 characters
- lowercased again → strasse, still 7 and no longer the original word
- "I" lowercased in English → "i"
- "I" lowercased in Turkish → "ı", a different character entirely
Length changed, the round trip lost information, and the correct answer for one of the inputs depends on who is reading it. Any code that assumes case conversion is a reversible one-to-one mapping is wrong on both counts.
Reading the result
- Never case-fold for comparison using toUpperCase or toLowerCase alone. Unicode defines a separate case-folding operation for exactly this purpose; using display-oriented conversion to compare identifiers produces mismatches that appear only for certain languages.
- The Turkish dotted and dotless i is the classic locale bug. Lowercasing an ASCII I in a Turkish locale yields ı, so a case-insensitive comparison of file names, commands or usernames silently fails for Turkish users and nobody else.
- Title case is not a Unicode operation but an editorial convention, and it differs between style guides and between languages. German capitalises all nouns; English style guides disagree with each other about short prepositions. No library setting makes this correct everywhere.
- Programming case styles carry their own hazards. Converting to camelCase and back through snake_case is lossy once acronyms are involved — parseHTTPResponse and parseHttpResponse both map to the same snake form and cannot be told apart on the way back.
Common questions
- Why did my text get longer after uppercasing?
- Because some characters expand. German ß becomes SS, and several ligatures decompose the same way. Any layout, database column or validation rule that assumes case conversion preserves length will eventually break on real input.
- How should I compare two strings ignoring case?
- Use case folding rather than uppercasing or lowercasing, and specify the locale when a language context exists. Naive lowercasing is correct for ASCII and produces wrong answers for Turkish, German and several other languages.