Text cases, and which to use where
Why title case is harder than it looks, what each programming convention is for, and the locale rule that breaks naive uppercasing.
Last reviewed · 1,284 words
In short
- Title case is not "capitalise every word". Style guides keep articles, short prepositions and conjunctions lowercase unless they start or end the title.
- camelCase, PascalCase, snake_case and kebab-case each belong to specific contexts, and mixing them within one codebase is the actual problem.
- Uppercasing is not reversible. Once "US" and "us" both become "US", the original is gone.
- Turkish has a dotless i, so uppercasing "i" without a locale produces the wrong letter. This has broken real software.
- Sentence case is the most readable option for headings and is increasingly the default in modern interfaces.
Changing the case of text is mechanically trivial and conventionally full of edge cases, which is why a converter that does it properly is more useful than one that calls toUpperCase().
The prose cases
UPPERCASE. Every letter capitalised. Used for acronyms, some legal headings, and emphasis — where it reads as shouting and reduces reading speed by 10% to 20%, because word shape disappears.
lowercase. Everything down. Used for URLs, email addresses, hashtags in some styles, and as a deliberate stylistic choice.
Sentence case. First letter capitalised, the rest as written. The most readable option for headings, and now the default in most modern interfaces including Google's and Apple's guidelines.
Title Case. Principal words capitalised. Standard for book titles, article headlines and academic references — and the one that is genuinely difficult.
Why title case is hard
"Capitalise every word" is wrong, and the correct rule depends on which style guide you follow.
The common core, shared by most guides:
- Capitalise nouns, pronouns, verbs, adjectives and adverbs
- Lowercase articles (a, an, the), coordinating conjunctions (and, but, or, nor, for, yet, so) and short prepositions
- Always capitalise the first and last word, whatever they are
Where the guides part company:
| Guide | Prepositions | Notable rule |
|---|---|---|
| Chicago | Lowercase all, any length | "Through" stays lowercase |
| AP | Lowercase under 4 letters | "With" is capitalised |
| APA | Lowercase under 4 letters | Capitalise both parts of a hyphenated major word |
| MLA | Lowercase all | Similar to Chicago |
So "The Man Who Fell to Earth" is correct under all of them, and "A Journey Through Time" is Chicago while "A Journey Through Time" with a capital T is AP.
The other trap is words that are sometimes prepositions and sometimes not. "Run Up the Hill" capitalises "up" because it is part of the verb; "Run up the Hill" would be wrong. No automated converter reliably resolves this, which is why title case output is worth reading before using.
The programming cases
Each convention belongs somewhere specific, and the value of following them is that a reader can infer what a name refers to from its shape.
| Case | Example | Where it belongs |
|---|---|---|
| camelCase | userAccountId | JavaScript and Java variables and functions |
| PascalCase | UserAccount | Class and component names; C# generally |
| snake_case | user_account_id | Python, Ruby, SQL columns |
| SCREAMING_SNAKE_CASE | MAX_RETRY_COUNT | Constants, environment variables |
| kebab-case | user-account-page | URLs, CSS classes, HTML attributes, filenames |
| dot.case | app.config.database | Configuration keys, namespaces |
| Train-Case | X-Custom-Header | HTTP headers |
kebab-case for URLs is worth stating separately: search engines treat hyphens as word separators and underscores as joiners, so blue-widgets reads as two words and blue_widgets as one. Use hyphens in URLs, always.
The consistency matters more than the choice. A codebase mixing getUserName, get_user_name and GetUserName for equivalent things costs its readers something on every file.
Cases that need care
Toggle case and aLtErNaTiNg CaSe exist and have essentially one use, which is to signal mockery on the internet.
Small caps is typography rather than case — the letters are lowercase rendered in capital forms, which no case conversion produces.
Uppercasing is lossy
Case conversion is not always reversible, and the failures are worth knowing.
Uppercase destroys information. "US" and "us" both uppercase to "US", and nothing recovers which was which. This is why databases should not store text uppercased for comparison purposes; compare case-insensitively instead.
German ß. Uppercasing "straße" gives "STRASSE" — two characters where there was one, so the string length changes. A capital ẞ exists and is not commonly used.
Turkish and Azerbaijani dotted i. Turkish has two distinct letters: dotted i/İ and dotless ı/I. Uppercasing "i" in a Turkish locale gives "İ", not "I".
That last one has broken real software repeatedly. A program uppercasing a string to compare it against "INDEX" gets "İNDEX" on a Turkish system, the comparison fails, and the failure appears only for users in one country. The fix is to use an invariant or locale-neutral case operation for anything that will be compared programmatically, and a locale-aware one only for text shown to a person.
Greek final sigma. ς at the end of a word and σ elsewhere both uppercase to Σ, and lowercasing back requires knowing the position.
Where each belongs
Headings and buttons. Sentence case. It reads faster, avoids the title case arguments entirely, and is what Google's Material and Apple's Human Interface guidelines both now recommend.
Book and article titles. Title case, following whichever guide the publication uses.
Navigation labels. Sentence case, or title case if the rest of the product uses it. Consistency within one interface matters more than which.
URLs. Lowercase kebab-case, always. Mixed-case URLs create duplicate-content problems on case-sensitive servers.
Email addresses. Lowercase for storage and comparison. The local part is technically case-sensitive under the standard and no real mail server treats it that way.
Acronyms in identifiers. parseHtml or parseHTML? Most modern style guides prefer treating the acronym as a word — parseHtml, HttpClient — because it keeps the boundaries readable in longer names like parseHtmlUrlPath.
Legal text. The convention of putting warranty disclaimers in full uppercase comes from a requirement that they be "conspicuous", and it is widely criticised for making them harder to read, which is arguably the opposite of the intent.
Brand names and proper nouns
Case conversion has no way to know that "iPhone", "eBay", "LaTeX", "IKEA" and "WhatsApp" are spelled the way they are deliberately.
Title-casing "iphone" produces "Iphone". Uppercasing "LaTeX" produces "LATEX", which is a different word to anyone in publishing. Sentence-casing a line beginning with "eBay" produces "EBay".
There is no automated solution short of a dictionary of exceptions, which every implementation gets partially right. Read the output when proper nouns are involved, which is most of the time in commercial writing.
The same applies to acronyms mid-sentence. "NASA announced" survives sentence case; "the NASA report" does not survive title case cleanly under every convention, and initialisms inside identifiers are a settled argument only within a given style guide.
Case sensitivity, where it bites
Different systems draw the line differently, and the boundaries cause real bugs.
Filesystems. Linux is case-sensitive; Windows is not; macOS is
case-insensitive by default and case-preserving. A project importing ./Utils.js
works on a developer's Mac and fails on a Linux build server where the file is
utils.js. This is one of the most common causes of a build that works locally
and not in CI.
URLs. The domain is case-insensitive; the path is case-sensitive on most
servers. example.com/About and example.com/about can be two different pages,
which splits ranking signals and creates duplicate content.
Email. The domain is case-insensitive. The local part is technically case-sensitive under the standard and treated as insensitive by every mail provider in practice — so store it lowercase and compare it lowercase.
Databases. MySQL string comparison is case-insensitive by default depending on collation; PostgreSQL is case-sensitive. The same query returns different results on the two, which is a migration hazard rather than a bug in either.
Programming languages. Almost all are case-sensitive. SQL keywords are not,
which is why SELECT and select both work and why teams argue about which to
write.
What this tool assumes
- Title case follows a common English convention with a standard list of small words kept lowercase; verify against your own style guide.
- Case conversion is locale-neutral, so Turkish dotted and dotless i are handled by the standard mapping rather than the Turkish one.
- Existing capitalisation inside words — acronyms, brand names like iPhone — may not survive conversion, so check the output.
- Programming case conversions split on existing boundaries: spaces, hyphens, underscores and capital letters.
- Everything runs in your browser. Nothing you paste is sent anywhere.