How to Convert Text Between Cases

Naming conventions matter. Whether you are writing code, creating file names, or formatting headings, using the right text case keeps things consistent and professional. Converting between cases manually is tedious and error-prone, especially with long text or variable names. A browser-based converter handles every common case format instantly.

Common text cases and where they are used

How to convert text case

1. Paste your text: enter any text into the converter. It works with single words, variable names, sentences, or entire paragraphs.
2. Choose a case: click the format you want. The conversion applies instantly.
3. Copy the result: click Copy to grab the converted text for your code, document, or file name.

A brief history of naming conventions in code

Early programming languages had hard limits on identifier length: FORTRAN (1957) allowed 6 characters; ALGOL (1958) allowed limited characters. Programmers had to abbreviate aggressively. There was no need for case conventions because identifiers were too short to have multiple words.

When languages allowed longer identifiers (C 1972, Pascal 1970), separating words became a question. Pascal popularized using capital letters to separate words: MyVariable. C historically used lowercase with underscores: my_variable. The split has persisted: most C-family and Unix languages prefer snake_case (Python, Ruby, Rust by default, PostgreSQL columns), while Java-family and Microsoft languages prefer camelCase (JavaScript, Java, C#, Swift, Kotlin).

PascalCase emerged from Smalltalk (1980s) for class names, then was adopted by C++ (1985), Java (1995), and C# (2000). Today most languages use PascalCase for types/classes and camelCase for instances/functions, regardless of word-separator preference.

kebab-case appeared with the Web: CSS chose hyphens (background-color) and URLs prefer them too. Most modern web languages (HTML, CSS, URL paths, JSON schemas) use kebab-case for identifiers visible to the user.

The newest convention is SCREAMING_SNAKE_CASE for constants and environment variables: a Unix shell legacy that crossed over into most programming languages by the 2000s.

When to use each convention

A practical guide:

• UPPERCASE in prose: acronyms (NASA, HTML, CSS), emphasis (rarely; bold is usually better), headings in design systems that specify it.
• lowercase in prose: URLs, email addresses, hashtags, casual chat. In code: rarely, except for some Lisp variants.
• Title Case: book titles, article headings, proper nouns. Different style guides have different rules about which words to capitalize.
• Sentence case: standard for body text, descriptions, UI labels in modern design systems (Material Design, Apple HIG both prefer Sentence case for buttons).
• camelCase: JavaScript/TypeScript variables, Java/Swift method names, instance variables in most OO languages.
• PascalCase: class names, type names, React/Vue component names, enum types.
• snake_case: Python and Ruby variables/functions, database column names, GraphQL field names (sometimes), shell variables.
• SCREAMING_SNAKE_CASE: constants in most languages, environment variables (DATABASE_URL, NODE_ENV), config keys in YAML/JSON.
• kebab-case: URL slugs, CSS class names, HTML data-* attributes, npm package names, file names in static-site generators.
• dot.case: object property paths in code, config files (Nginx, Spring Boot properties), namespaced events.

Title Case rules

"Title Case" sounds simple but has style-guide complications:

• APA style: capitalize words of 4+ letters; capitalize all nouns, verbs, adjectives, adverbs regardless of length.
• Chicago Manual of Style: capitalize first/last words; capitalize all nouns, verbs, adjectives, adverbs, pronouns; lowercase articles (a, an, the), short prepositions, coordinating conjunctions (and, but, or).
• AP style: capitalize all words of 4+ letters; specific exceptions for prepositions.
• MLA style: similar to Chicago but with slight differences in preposition handling.

A "simple title case" converter capitalizes every word (which technically only matches no major style guide). Most converters offer "Title Case" as a quick estimate but flag the result for manual review of:

• Articles (a, an, the)
• Conjunctions (and, but, or, for, nor)
• Short prepositions (in, on, at, by, to, of)
• Acronyms (API, HTTP, CSS)

Common pitfalls

• Acronyms in camelCase: xmlHTTPRequest is awkward. Google's JavaScript style guide recommends treating acronyms as words: xmlHttpRequest or XmlHttpRequest. Microsoft and Java style guides keep them all-uppercase: XMLHttpRequest. Pick a convention.
• Numbers in identifiers: version2Point0 vs version2_0 vs version20. No universal rule; depends on language convention.
• Initial-letter-capitalized acronyms: "i18n" is camelCase, "I18n" is PascalCase, "I18N" is screaming. Match your context.
• Title Case on prepositions: "Off The Record" looks wrong to most editors; "Off the Record" follows most style guides. Verify before publishing.
• Database case conventions vary: PostgreSQL and most SQL implementations are case-insensitive for unquoted identifiers but case-sensitive for quoted ones. SELECT myColumn FROM table may fail if the actual column name is mycolumn.
• Filename case sensitivity by OS: macOS HFS+ is case-insensitive by default; APFS is case-insensitive but case-preserving; Linux ext4 is case-sensitive; Windows NTFS is case-insensitive (but Linux subsystems on Windows are case-sensitive). MyFile.txt and myfile.txt may or may not be the same file.
• Unicode case is locale-dependent: capital İ (Turkish dotted I) vs I (English). Some toUpperCase() implementations get this wrong without explicit locale.

Tips

• Match the convention of your language: Python uses snake_case, JavaScript uses camelCase, and CSS uses kebab-case. Consistency within a codebase is more important than personal preference.
• Unicode is supported: the converter handles accented characters, emoji, and CJK characters, so it works with text in any language.
• Check acronyms in Title Case: most title case converters capitalize every word, which can turn "API" into "Api." Review acronyms after converting.
• Use Sentence case for readability: for user-facing text like button labels and descriptions, sentence case is often easier to read than Title Case.
• Configure your linter: ESLint, Prettier, Pylint, RuboCop can all enforce naming conventions automatically. Set them up once and let the linter catch case violations on save.
• Use a code-style guide: Google, Airbnb, Microsoft, GitHub all publish style guides for major languages. Pick one for your project and stick with it.

Privacy and confidential text

The case converter runs entirely in your browser. The text you paste, intermediate conversions, and the output all stay on your device. Nothing is uploaded to a server, logged, or shared with anyone.

This matters because the strings you convert are often confidential: variable names from proprietary codebases, internal API endpoints, draft article titles, customer-facing copy under embargo, database column names that reveal product structure. Cloud case converters log every conversion in their request logs and may use them for "improvement" or analytics. A browser-only converter has zero exposure, and works offline once the page is loaded.