ToolSink
Back to blog

Text Case Conversion: Styles, When to Use Each, and How to Convert Programmatically

ToolSink Team

Text case isn't just a style preference — in code, it's often a hard convention enforced by linters or frameworks; in writing, it signals formality and affects readability in measurable ways.

The standard cases

  • lowercase — every letter uncapitalized; standard for email addresses, URLs, casual text
  • UPPERCASE — every letter capitalized; used for acronyms (NASA, FBI) and emphasis, but reads as shouting and increases reading fatigue over long stretches — the letters' uniform height removes the shape cues that help the eye track a line of text
  • Title Case — major words capitalized, minor words (and, but, for, or) lowercase; standard for headlines and titles
  • Sentence case — only the first word and proper nouns capitalized; the default for body text and most professional writing
  • camelCase — first word lowercase, each subsequent word capitalized; standard for variables/functions in JavaScript, Java, C#
  • PascalCase — like camelCase but the first word is also capitalized; standard for class names in most OOP languages
  • snake_case — lowercase, words joined with underscores; standard for Python/Ruby variables and functions
  • kebab-case — lowercase, words joined with hyphens; the standard for URLs and CSS class names

Where each one is actually expected

Writing: Sentence case for body text, Title Case for headlines/titles, uppercase reserved for acronyms only — sticking to sentence case for long-form content isn't just convention, it measurably reduces reading effort compared to all-caps blocks.

Code: Case convention is often enforced by the language/framework rather than optional — JavaScript's ecosystem expects camelCase for variables and PascalCase for classes/components; Python's style guide (PEP 8) expects snake_case; mixing conventions within one codebase creates visual noise for anyone reading it.

URLs: kebab-case is the practical standard. The actual reason: search engines have historically parsed hyphens as word boundaries (text-case-guide reads as three separate keyword tokens) while treating underscores as part of a single joined string. This is a keyword-parsing and readability difference, not a crawl error — underscored URLs still get indexed, they just don't separate into distinct keyword tokens as cleanly.

Converting between cases programmatically

If you're normalizing a dataset or refactoring variable names at scale, here's the actual logic rather than a manual find-replace:

function toCamelCase(str) {
  return str
    .toLowerCase()
    .replace(/[-_\s]+(.)?/g, (_, c) => (c ? c.toUpperCase() : ''));
}

function toSnakeCase(str) {
  return str
    .replace(/([a-z])([A-Z])/g, '$1_$2') // split camelCase boundaries
    .replace(/[-\s]+/g, '_')
    .toLowerCase();
}

function toKebabCase(str) {
  return toSnakeCase(str).replace(/_/g, '-');
}

toCamelCase('user_first_name');   // "userFirstName"
toSnakeCase('userFirstName');     // "user_first_name"
toKebabCase('userFirstName');     // "user-first-name"

import re

def to_snake_case(name: str) -> str:
    s1 = re.sub(r'(.)([A-Z][a-z]+)', r'\1_\2', name)
    return re.sub(r'([a-z0-9])([A-Z])', r'\1_\2', s1).lower()

to_snake_case("HTTPResponseCode")  # "http_response_code"

Note the last example: naive camelCase-to-snake_case regexes often mishandle consecutive capitals (like HTTPResponseCode or userID) — worth testing against a few edge cases like that before trusting a conversion script on a real codebase.

Best practices

  1. Pick a style guide and document it — for a team, this removes case choice as a recurring code review debate
  2. Stay consistent within a document/codebase — mixing Title Case and sentence case across headings in the same article, for instance, reads as sloppy even if each individual heading is technically fine
  3. Default to sentence case for body text — it's measurably easier to read at length than uppercase or inconsistent capitalization

For quick manual conversion without scripting, ToolSink's Case Converter handles all of the above styles directly in the browser.

Conclusion

Text case conventions exist for real, mostly non-arbitrary reasons — readability for prose, language convention for code, keyword parsing for URLs. Getting them right isn't about rigid rule-following so much as matching the convention actually expected in each specific context.

Back to blog