The Complete Guide to Text Case: When to Use UPPERCASE, lowercase, and Everything Between

Most people treat text case like a preference — a stylistic choice somewhere between choosing a font and deciding how many exclamation points is too many. But casing conventions carry genuine semantic weight. The difference between writing getUserName and GetUserName in certain languages is the difference between a private method and a public one. Writing a headline in Title Case instead of Sentence case signals different things to readers depending on whether they're reading a newspaper or a GitHub README. And ALL CAPS in a message to a coworker? You might as well be standing on your desk.

This guide goes deep on every major text case type — not just what it looks like, but why it exists, where it evolved from, and exactly when you should (and shouldn't) use it.

Sentence case

Only the first word of a sentence is capitalized, along with proper nouns. This is how you were taught to write in school, and it's the default register for most human communication: emails, chat messages, blog body copy, documentation paragraphs, and social media posts.

Sentence case feels natural because it is natural — it maps directly to how we process spoken language. The capital letter at the beginning of a sentence is a visual breath, a signal that something new is starting. Everything else stays lowercase so those signals don't compete.

Where it fits best: long-form prose, UI body copy, notification messages, tooltips, and any context where readers scan rather than read. Product teams at companies like Stripe and Linear have written explicit style guides mandating sentence case for their entire UI — partly for readability, partly because it reads as less formal and more conversational, which aligns with their brand tone.

Where it breaks: headlines and titles in journalism (more on that below), and anywhere you're deliberately signaling formality or elevation.

Title Case

Major words are capitalized; prepositions, articles, and conjunctions under a certain length stay lowercase. The exact rules differ by style guide — AP, Chicago, APA, and MLA all disagree on edge cases like whether to capitalize "with" or what counts as a "major" word.

Title Case originated in print publishing as a way to visually distinguish headlines and titles from body text at a time when typography options were limited. If you couldn't make something bold, you used casing. That legacy persists in newspaper headlines, book titles, film names, and chapter headings.

The problem: Title Case is genuinely hard to apply correctly. Most people guess at it. The rule isn't "capitalize words over four letters" — it's more nuanced. Chicago style, for example, capitalizes prepositions only when they're stressed or used as adverbs. So "Turning Up the Heat" capitalizes "Up" because it's part of a phrasal verb, but "A Study in Contrasts" lowercases "in" because it's a preposition. Very few writers get this right consistently without a style guide open.

Where it fits best: book and film titles, formal report headings, chapter names, and any editorial context where the house style explicitly calls for it.

Where it doesn't: product UIs (looks stiff), casual blog posts (feels overworked), and anywhere you want to sound like a person rather than a publication.

ALL UPPERCASE

Every character capitalized. Historically, this had a practical origin in typewriting and early digital systems where lowercase wasn't always available — military communications, early computing, legal documents, and telegraph messages all defaulted to uppercase partly out of necessity.

Today, ALL CAPS carries strong connotations of urgency, anger, or emphasis. In online communication, it reads as shouting — a convention so deeply embedded that it transcends generational gaps. A 70-year-old and a 14-year-old both interpret "WHY DIDN'T YOU CALL" the same way.

Legitimate contemporary uses: acronyms (NASA, HTML, API), warning labels ("CAUTION: HOT SURFACE"), constants in certain programming languages (Python and C conventions use MAX_RETRY_COUNT for module-level constants), and decorative display typography where a designer has made a deliberate aesthetic choice.

Where it actively hurts you: email subject lines (spam filters and recipients both penalize it), body text of any length (readability drops sharply — the lack of ascenders and descenders in all-caps text removes the visual anchors readers use to distinguish letters at a glance), and anywhere you want to be taken seriously rather than noticed desperately.

lowercase (all of it)

Every character lowercase, including proper nouns and sentence starts. This is a deliberate stylistic choice with a particular cultural history. poets like e.e. cummings made it famous as a form of anti-establishment self-expression. In the early internet era, IRC and early chat culture normalized all-lowercase as a speed optimization — shift keys cost milliseconds. Later it became a Gen Z aesthetic marker: casual, understated, implying that you're too relaxed to bother with the shift key.

Brands have used this deliberately. The pop musician lorde stylized her name in lowercase in early promotional materials. Certain tech products use all-lowercase for a minimal, modern feel.

In code: CSS property names are all lowercase. JSON keys are conventionally lowercase. URLs are lowercase. HTML5 attributes are lowercase. In these contexts, lowercase isn't a choice — it's a requirement for correctness.

Where it's a problem: formal correspondence, anything that will be parsed by a system expecting proper capitalization (names in databases, for instance), and academic or professional documents where convention is part of signaling competence.

camelCase

The first word is lowercase, and each subsequent word starts with an uppercase letter. camelCase. userAccountSettings. parseHttpResponse.

This exists entirely because of programming. When whitespace can't be used in identifiers (variable names, function names, class properties), developers needed another way to make multi-word names readable. camelCase became the dominant convention in Java, JavaScript, and many derived languages.

Two variants matter here. Lower camelCase (also called lowerCamelCase): the version described above, used for variable and function names in JavaScript (const getUserById), Java methods, Swift variables. Upper camelCase — also called PascalCase — is discussed separately below.

A subtlety worth knowing: acronyms inside camelCase identifiers are genuinely contested. Should it be parseHTTPResponse or parseHttpResponse? Google's Java Style Guide says treat acronyms as words: parseHttpResponse. Microsoft's C# guidelines historically kept acronyms uppercase for two-letter abbreviations (IOStream) but not longer ones. If you're joining a codebase, follow whatever it already does. If you're starting from scratch, pick one rule and stick to it obsessively.

PascalCase (Upper CamelCase)

Every word starts with a capital letter, including the first. UserAccountSettings. ParseHttpResponse. MyComponentName.

PascalCase is named after the Pascal programming language, though it predates it slightly in usage. In most languages that use camelCase for variables and methods, PascalCase is used for types, classes, and constructors. In React, component names must be PascalCase — the JSX parser distinguishes between built-in HTML elements (<div>) and custom components (<MyComponent>) precisely by whether the name starts with an uppercase letter.

In C#, PascalCase is used for everything public: methods, properties, classes, interfaces. Go uses PascalCase for exported (public) identifiers and lowerCamelCase for unexported ones — the capitalization literally controls visibility at the package level.

Outside programming: it's occasionally used in brand names (YouTube, LinkedIn, WordPress) and sometimes in design system documentation.

snake_case

Words separated by underscores, all lowercase. user_account_settings. parse_http_response. max_retry_count.

Snake case is particularly dominant in Python (where PEP 8, the style guide most Python developers follow, mandates it for variables and functions), Ruby, PHP, and database column names across virtually every SQL flavor. It's also the convention for file names in Linux/Unix systems — spaces in filenames create shell escaping nightmares, so underscores are used instead.

The underscore as separator has a readability advantage in certain contexts: it most closely mimics a space character visually, making user_account_settings marginally easier to scan than userAccountSettings for people less accustomed to camelCase.

SCREAMING_SNAKE_CASE — all uppercase with underscores — is the conventional choice for constants in Python, C, C++, and Rust. MAX_CONNECTIONS. DEFAULT_TIMEOUT_MS. The all-caps signals "this value doesn't change," and the underscores keep it readable.

kebab-case

Words separated by hyphens, all lowercase. user-account-settings. my-component-name. Named for skewered meat — the hyphens look like the skewer.

Kebab case is the default in CSS (background-color, font-size, border-top-left-radius) and HTML attributes. It's also the standard for URL slugs — this very article's URL almost certainly uses kebab-case — because hyphens in URLs are treated as word separators by search engine crawlers, while underscores are not. This matters for SEO: text-case-guide is indexed as three words; text_case_guide is indexed as one undifferentiated string by Google.

The catch: kebab-case can't be used as an identifier in most programming languages because the hyphen is a subtraction operator. user-name = "Pawan" parses as user minus name equals a string, which is a syntax error. This is why JavaScript object properties that use kebab-case require bracket notation: obj["background-color"] instead of obj.background-color.

Mixing Cases: When the Rules Collide

Real work involves crossing context boundaries constantly. A React developer writes PascalCase component names, camelCase props, snake_case for any Python API they're calling, kebab-case for their CSS class names, and SCREAMING_SNAKE_CASE for their environment variables — all in the same afternoon.

The mental model that helps: think of case as a communication protocol. Within a given context (a codebase, a style guide, a platform), everyone has to use the same protocol or nothing parses correctly. The choice of protocol is often arbitrary at first — snake_case versus camelCase is genuinely not a readability-determined outcome, it's a historical accident of which language community you're in. Once chosen, though, consistency matters far more than the specific choice.

Case conversion tools exist precisely because these boundaries are crossed constantly. A developer receiving JSON with user_name and passing it into a JavaScript object might need to convert to userName programmatically. A content manager copying a title from a brief into a CMS needs to re-case it from all-caps brief formatting to proper Title Case. The friction of these conversions is real and daily.

Understanding what each case type actually means — not just what it looks like — makes you faster at these transitions, better at choosing the right convention for a new project, and more precise in the way you communicate through text, whether to humans or machines.