Developer Reference

Text Case Conversion Guide: UPPERCASE, lowercase, Title Case, and More

Published April 20, 2026 · 12 min read

Text case is one of those details that seems trivial until it causes a bug, a failed linter check, or a URL that breaks because someone mixed capitalization styles. Whether you are writing prose, naming variables, constructing URLs, or defining database columns, the case convention you choose communicates intent and carries real consequences for readability, compatibility, and machine parsing.

This guide covers every major text case convention in detail: the writing cases used in natural language (UPPERCASE, lowercase, Title Case, Sentence case), the programming cases used in source code (camelCase, PascalCase, snake_case, kebab-case, SCREAMING_SNAKE_CASE), and the rules that govern when and where to use each. It includes code examples for converting between cases, a language-by-language reference table, and practical guidance for choosing the right convention in every context.

What Is Text Case?

Text case refers to the distinction between uppercase (capital) and lowercase (small) letters in a writing system. In the Latin alphabet used by English and most European languages, every letter exists in two forms: an uppercase variant (A, B, C) and a lowercase variant (a, b, c). The choice of which form to use, and the pattern in which they are combined, is what we call a case convention.

Case matters for two fundamental reasons. In natural language, case signals the start of a sentence, identifies proper nouns, and conveys emphasis. In programming, case is a structural convention that encodes meaning into identifiers: a className is visually and semantically distinct from a class_name, and most languages treat them as entirely different symbols because identifiers are case-sensitive.

The terms "uppercase" and "lowercase" originate from the physical layout of metal type in printing. In a traditional print shop, capital letters were stored in the upper case (the higher of two type cases on the compositor's desk), while small letters were in the lower case. The terms have survived centuries of technology changes and remain the standard terminology in Unicode, programming, and typography.

UPPERCASE and lowercase

UPPERCASE (also called ALL CAPS or capital letters) converts every letter in the text to its capital form. In typography, these are called majuscules — from the Latin maiusculus, meaning "somewhat larger." UPPERCASE is used for acronyms (NASA, HTTP, CSS), headings, legal notices, and emphasis. In programming, it designates constants (see SCREAMING_SNAKE_CASE below).

lowercase converts every letter to its small form. In typography, these are minuscules. Lowercase is the default for running text, variable names in most languages, URLs, email addresses, and file names. Lowercase text is generally easier to read in body copy because the ascenders and descenders of minuscule letters (the upward strokes of b, d, h and the downward strokes of g, p, y) create a more varied and recognizable word shape.

Unicode Considerations

Case conversion is not as simple as flipping a bit. Unicode defines case mappings for thousands of characters, and some conversions are locale-dependent: the Turkish letter I lowercases to ı (dotless i), not the standard i. The German sharp s ß uppercases to SS — a one-to-two character expansion. Production-grade case conversion should use locale-aware functions like JavaScript's toLocaleUpperCase('tr').

Title Case

Title Case capitalizes the first letter of major words while leaving minor words (articles, short prepositions, short conjunctions) in lowercase. It is the standard for headlines, book titles, article titles, and UI headings. The exact rules depend on which style guide you follow.

AP Style

The Associated Press Stylebook capitalizes all words of four or more letters. Words of three or fewer letters are lowercased unless they are the first or last word of the title. Lowercased words include: a, an, the, and, but, or, nor, for, yet, so, at, by, in, of, on, to, up.

Chicago Manual of Style

Chicago style lowercases articles (a, an, the), coordinating conjunctions (and, but, or, nor, for, yet, so), and all prepositions regardless of length (between, through, after) unless they are the first or last word. This means "Running Through the Forest" is correct in AP style (because "Through" has seven letters) but incorrect in Chicago, which would render it "Running through the Forest."

Universal Rules

• Always capitalize the first and last word, regardless of part of speech.
• Always capitalize nouns, verbs, adjectives, adverbs, and pronouns.
• Capitalize both parts of a hyphenated compound if both are major words: "Self-Driving Cars," not "Self-driving Cars."
• Capitalize the first word after a colon: "JavaScript: The Good Parts."

Example: "the quick brown fox jumps over the lazy dog" becomes "The Quick Brown Fox Jumps Over the Lazy Dog" in AP style and "The Quick Brown Fox Jumps over the Lazy Dog" in Chicago style (because "over" is a preposition).

Sentence Case

Sentence case capitalizes only the first word of the sentence and any proper nouns. Everything else is lowercase. Example: "How to convert text case in JavaScript" — only "How" is capitalized (plus "JavaScript" as a proper noun). Google's Material Design guidelines and Apple's Human Interface Guidelines default to sentence case for headings, buttons, and labels because it eliminates ambiguity about which words should be capitalized.

camelCase

camelCase joins multiple words into a single identifier by removing spaces and capitalizing the first letter of each word except the first. The resulting "humps" in the middle of the word resemble a camel's back, hence the name. Examples: getUserName, isValidEmail, parseJsonResponse.

camelCase originated in the Smalltalk programming community in the 1970s and was popularized by Java in the 1990s. Today it is the dominant convention for variable names and function names in JavaScript, TypeScript, Java, C#, Swift, and Kotlin. It is also the standard for JSON property names in most REST API conventions.

The rules are straightforward: the first word is entirely lowercase, and every subsequent word begins with an uppercase letter. No separators (underscores, hyphens, spaces) are used. Acronyms are a source of debate — some style guides write parseXml (treating the acronym as a word), while others write parseXML (preserving the acronym's capitalization). The first approach is generally preferred because it avoids ambiguity: XMLHTTPRequest is harder to parse visually than xmlHttpRequest.

PascalCase

PascalCase (also called UpperCamelCase) follows the same rules as camelCase except that the first letter is also capitalized. Examples: UserProfile, HttpResponse, DatabaseConnection.

The name comes from the Pascal programming language, which used this convention for identifiers. PascalCase is the near-universal convention for class names and type names across programming languages. In React, component names must start with an uppercase letter (UserCard, not userCard) — this is how JSX distinguishes between custom components and HTML elements. TypeScript interfaces and type aliases also follow PascalCase: interface UserProfile, type ApiResponse.

C# uses PascalCase more broadly than most languages: public methods, properties, and namespaces all use PascalCase in C# conventions, while private fields use camelCase with a leading underscore (_userName).

snake_case

snake_case separates words with underscores and uses all lowercase letters. Examples: user_name, get_user_by_id, max_retry_count.

snake_case is the dominant convention in Python (PEP 8 mandates it for variables, functions, and module names), Ruby, Rust (for variables and functions), Elixir, and PHP. It is also the standard naming convention for database tables and columns in PostgreSQL, MySQL, and most SQL databases: user_profiles, created_at, order_line_items.

Research from Binkley et al. (2009) found that snake_case identifiers are read more accurately by programmers because the underscores provide explicit word boundaries. In practice, the choice is determined by language convention — consistency within a codebase matters more than any absolute readability advantage.

kebab-case

kebab-case (also called hyphen-case, dash-case, or lisp-case) separates words with hyphens and uses all lowercase letters. Examples: nav-primary, btn-submit-large, user-profile-card.

kebab-case is the standard for CSS class names and IDs (.header-nav, #main-content), HTML custom data attributes (data-user-id), URL slugs (/articles/case-converter-guide), file names in many projects (case-converter-guide.html), and npm package names (lodash-es, react-router-dom).

kebab-case cannot be used for variable names in most programming languages because the hyphen is interpreted as a minus operator. user-name would be parsed as user minus name. The exceptions are Lisp dialects (Clojure, Common Lisp) and CSS custom properties, where hyphens in identifiers are syntactically valid.

SCREAMING_SNAKE_CASE

SCREAMING_SNAKE_CASE (also called CONSTANT_CASE or UPPER_SNAKE_CASE) combines the structure of snake_case with the emphasis of UPPERCASE. Every letter is capitalized, and words are separated by underscores. Examples: MAX_RETRIES, API_BASE_URL, DEFAULT_TIMEOUT_MS.

This convention is nearly universal for constants — values that are defined once and never change. It is used in JavaScript (const MAX_SIZE = 100), Python (MAX_CONNECTIONS = 50), Java (static final int BUFFER_SIZE = 1024), Rust (const MAX_THREADS: usize = 8), C/C++ (#define MAX_LENGTH 256), and Go (exported constants: MaxRetries follows PascalCase, but environment variable-style constants use SCREAMING_SNAKE_CASE).

The all-caps formatting provides an immediate visual signal to anyone reading the code: this value is a constant, do not modify it, and it was intentionally given a fixed value at definition time. Linters in most languages will flag a SCREAMING_SNAKE_CASE identifier that is reassigned.

Programming Conventions by Language

The following table summarizes the conventional case for each identifier type across major programming languages. Following these conventions is not optional in professional codebases — linters and style checkers enforce them, and deviating creates friction for every developer who reads your code.

Note: In Go, case has a functional purpose beyond convention. An identifier starting with an uppercase letter is exported (public), while lowercase is unexported (private). Case is part of Go's access control system.

Code Examples for Case Conversion

The following functions demonstrate how to convert between common case conventions programmatically. These are the core transformations that power any text case converter tool.

JavaScript

// camelCase to snake_case
function camelToSnake(str) {
  return str
    .replace(/([A-Z])/g, '_$1')
    .toLowerCase()
    .replace(/^_/, '');
}
// "getUserName" → "get_user_name"

// snake_case to camelCase
function snakeToCamel(str) {
  return str.replace(/_([a-z])/g, (_, c) => c.toUpperCase());
}
// "get_user_name" → "getUserName"

// Any string to kebab-case
function toKebab(str) {
  return str
    .replace(/([a-z])([A-Z])/g, '$1-$2')  // camelCase boundaries
    .replace(/[\s_]+/g, '-')               // spaces and underscores
    .toLowerCase();
}
// "getUserName" → "get-user-name"
// "user_profile_card" → "user-profile-card"

// Any string to Title Case (AP style simplified)
function toTitleCase(str) {
  const minor = new Set([
    'a','an','the','and','but','or','nor',
    'for','yet','so','at','by','in','of','on','to','up'
  ]);
  return str
    .toLowerCase()
    .split(' ')
    .map((word, i, arr) =>
      i === 0 || i === arr.length - 1 || !minor.has(word)
        ? word.charAt(0).toUpperCase() + word.slice(1)
        : word
    )
    .join(' ');
}
// "the quick brown fox" → "The Quick Brown Fox"

Python

import re

def camel_to_snake(text):
    """Convert camelCase or PascalCase to snake_case."""
    result = re.sub(r'(?<=[a-z0-9])([A-Z])', r'_\1', text)
    result = re.sub(r'(?<=[A-Z])([A-Z][a-z])', r'_\1', result)
    return result.lower().lstrip('_')
# "getUserName" → "get_user_name"
# "HTTPResponse" → "http_response"

def snake_to_camel(text):
    """Convert snake_case to camelCase."""
    parts = text.split('_')
    return parts[0] + ''.join(w.capitalize() for w in parts[1:])
# "get_user_name" → "getUserName"

def to_kebab(text):
    """Convert any string to kebab-case."""
    result = re.sub(r'([a-z])([A-Z])', r'\1-\2', text)
    result = re.sub(r'[\s_]+', '-', result)
    return result.lower()
# "getUserName" → "get-user-name"

def to_pascal(text):
    """Convert any string to PascalCase."""
    words = re.split(r'[\s_\-]+', text)
    return ''.join(w.capitalize() for w in words)
# "get_user_name" → "GetUserName"

When to Use Each Case

Choosing the right case convention is not about personal preference. It is about matching the expectations of the system you are working in. Using the wrong convention creates cognitive friction, breaks tooling, and signals that the author is unfamiliar with the domain.

For JSON APIs, the convention depends on your consumer: camelCase for JavaScript frontends, snake_case for Python/Ruby backends. The most important thing is consistency — pick one convention per API and enforce it everywhere.

Frequently Asked Questions