case-converter text-utility programming formatting

The Ultimate Case Converter: Transforming Text Style Instantly

Effortlessly switch between UPPERCASE, lowercase, camelCase, PascalCase, and more. A versatile tool for developers and writers.

2026-04-09 Use This Tool

What Is Text Case? A Brief History

Text case — the pattern of capitalisation applied to letters in a word or phrase — has been shaping written communication for centuries. In the age of handwritten manuscripts, scribes used capital letters to denote the beginning of sentences or proper nouns. The printing press formalised these conventions, and by the nineteenth century, typographers were distinguishing between upper case (capital letters stored in the upper part of a type case) and lower case (small letters stored in the lower part).

When typewriters arrived in the late 1800s, the shift key made switching between upper and lower case mechanical. Early computers inherited many typographic traditions, but programming languages introduced entirely new conventions driven by practical constraints: variable names couldn't contain spaces, identifiers needed to be distinguishable at a glance, and different ecosystems developed different preferences.

By the 1970s and 1980s, languages like C, Pascal, and Smalltalk were each nudging communities toward distinct naming styles. By the time the internet era arrived, conventions had multiplied: CSS had its own style, SQL had another, Python's PEP 8 formalised yet another. Today, a single full-stack developer routinely switches between four or five different casing conventions in a single workday — and that's exactly why a reliable case converter is indispensable.


Every Case Type Explained

camelCase

Words are joined together, with the first word entirely lowercase and each subsequent word beginning with a capital letter.

Example: myVariableName, getUserById, fetchDataFromApi

Used in: JavaScript (variables, functions), TypeScript (variables, functions), Java (variables, methods), Swift, Kotlin.

camelCase gets its name from the "hump" created by the internal capital letters, visually resembling a camel's back. It's the default for most C-family languages when naming non-class identifiers.

PascalCase (UpperCamelCase)

Like camelCase, but the very first letter is also capitalised. Every word starts with a capital.

Example: MyClassName, HttpRequestHandler, UserProfileService

Used in: C# (classes, interfaces, methods), TypeScript (classes, interfaces, enums), Java (classes, interfaces), .NET conventions broadly.

PascalCase signals "this is a type" in most statically typed languages. It was popularised by the Pascal programming language, though it predates it slightly in Smalltalk.

snake_case

Words are separated by underscores and all letters are lowercase.

Example: my_variable_name, get_user_by_id, calculate_total_price

Used in: Python (variables, functions, modules — mandated by PEP 8), Ruby, Rust, SQL column names, C standard library.

snake_case is beloved for readability in longer identifiers, since the underscore acts as a clear visual separator without requiring a shifted key.

kebab-case (spinal-case)

Words are separated by hyphens and all letters are lowercase.

Example: my-css-class, user-profile-card, background-color

Used in: CSS property names (font-size, border-radius), HTML attributes, URL slugs (/blog/my-article-title), Lisp, some configuration file keys (YAML, TOML).

kebab-case is not valid in most programming languages as a variable name (the hyphen is interpreted as subtraction), but it's the dominant convention everywhere that spaces are forbidden but symbols are allowed in identifiers.

SCREAMING_SNAKE_CASE (UPPER_SNAKE_CASE)

Like snake_case, but entirely uppercase.

Example: MAX_RETRY_COUNT, API_BASE_URL, DEFAULT_TIMEOUT_MS

Used in: Constants in virtually every language — Python (MAX_SIZE), JavaScript/TypeScript (const API_KEY), Java (static final), C macros, environment variables.

The all-caps styling serves as a visual signal: "this value does not change at runtime." Linters in most ecosystems will flag mutable variables named in SCREAMING_SNAKE_CASE and vice versa.

Title Case

Each significant word begins with a capital letter. Minor words (articles, prepositions, conjunctions) are often left lowercase according to style guides, though many implementations simply capitalise everything.

Example: My Article Title, The Quick Brown Fox, Introduction to Machine Learning

Used in: Article headings, book titles, UI button labels, marketing copy.

Title case rules vary by style guide (Chicago, APA, AP) — they all differ slightly on which words to leave lowercase. For most developer purposes, "capitalise every word" is a safe approximation.

Sentence case

Only the first letter of the first word is capitalised (plus proper nouns).

Example: My sentence starts here, This is a paragraph heading

Used in: Normal prose, some UI labels, blog post body text, most European language conventions for titles.

Sentence case is the default for natural written language and is often preferred in content-heavy UI (Material Design guidelines recommend it for body text and secondary labels).

flatcase (lowercase)

All letters lowercase, no separators.

Example: myvariable, httphandler, packagename

Used in: Go package names (e.g., fmt, http, strconv), some Python module names, Java package names conventionally.

flatcase trades readability for brevity. It works fine for short, single-concept names but becomes unreadable for compound words — hence Go's convention of using very short, single-word package names.


Why Naming Conventions Matter

Naming conventions are not aesthetic preferences — they are a form of communication. When an entire codebase uses consistent naming, developers can infer meaning from form alone:

  • Seeing MyClass in TypeScript immediately tells you it's a type, not a value.
  • Seeing MAX_CONNECTIONS tells you it's a constant, not a variable.
  • Seeing user_id in a SQL query tells you it's a database column.

Readability improves dramatically when conventions are consistent. Studies on code comprehension (Binkley et al., 2009) found that camelCase is read faster for short identifiers in code, while snake_case wins for longer compound words in prose-like contexts.

Team consistency reduces cognitive load during code review. If half the team writes getUserById and the other writes get_user_by_id, reviewers must constantly context-switch. Automated linters like ESLint (JavaScript), flake8 (Python), and golangci-lint (Go) can enforce naming conventions and eliminate this class of debate entirely.

Tooling support depends on conventions. IDE auto-complete, refactoring tools, and documentation generators all rely on consistent naming patterns to work correctly.


Language-Specific Naming Conventions

JavaScript and TypeScript

Variables & functions:    camelCase       (let userName, function getData)
Classes & interfaces:     PascalCase      (class UserService, interface IRepository)
Constants:                SCREAMING_SNAKE  (const MAX_SIZE = 100)
Enums:                    PascalCase      (enum Direction { North, South })
File names:               kebab-case      (user-service.ts, api-client.ts)
CSS modules / classes:    kebab-case      (.btn-primary, .card-header)

Python (PEP 8)

Variables & functions:    snake_case      (user_name, get_data)
Classes:                  PascalCase      (class UserService)
Constants:                SCREAMING_SNAKE  (MAX_SIZE = 100)
Modules:                  snake_case      (my_module.py)
Private members:          _single_leading_underscore (_internal_method)
Name mangling:            __double_leading_underscore (__private_attr)

Go

Exported identifiers:     PascalCase      (func GetUser, type UserService)
Unexported identifiers:   camelCase       (func getUser, var userCount)
Package names:            flatcase        (package http, package fmt)
Constants:                PascalCase or camelCase (no SCREAMING convention)

Go is unique in using case as a visibility modifier: PascalCase = public (exported), camelCase = private (unexported). This is enforced by the compiler.

Java

Variables & methods:      camelCase       (String userName, void getData())
Classes & interfaces:     PascalCase      (class UserService, interface Serializable)
Constants:                SCREAMING_SNAKE  (static final int MAX_SIZE = 100)
Packages:                 flatcase        (com.example.myapp)

CSS and HTML

Class names:              kebab-case      (.btn-primary, .nav-item)
Custom properties:        kebab-case      (--primary-color, --font-size-lg)
ID attributes:            kebab-case      (#main-content, #user-profile)

SQL / Databases

Table names:              snake_case      (user_profiles, order_items)
Column names:             snake_case      (first_name, created_at)
Stored procedures:        snake_case or PascalCase (get_user_by_id / GetUserById)

How the Case Converter Works Technically

A case converter must solve two fundamental problems:

  1. Word boundary detection — Given a string in any arbitrary casing, split it into its constituent words.
  2. Reassembly — Join those words back together in the target format.

Word boundary detection uses regular expressions to identify transitions:

  • Between a lowercase letter and an uppercase letter: camelCasecamel, Case
  • At underscore or hyphen characters: snake_casesnake, case
  • At whitespace characters: title casetitle, case
  • At digit boundaries (optional): base64Encodebase64, Encode

A robust tokeniser combines all these:

/([A-Z][a-z]+)|([A-Z]+(?=[A-Z][a-z]))|([A-Z]+$)|([a-z]+)|(\d+)/g

This pattern correctly handles edge cases like XMLParserXML, Parser and iOSi, OS.


Code Examples: Manual Conversion

Python

import re

def tokenize(text: str) -> list[str]:
    """Split any casing into a list of lowercase word tokens."""
    # Handle camelCase and PascalCase transitions
    text = re.sub(r'(?<=[a-z0-9])(?=[A-Z])', '_', text)
    text = re.sub(r'(?<=[A-Z])(?=[A-Z][a-z])', '_', text)
    # Split on separators
    words = re.split(r'[\s_\-]+', text)
    return [w.lower() for w in words if w]

def to_snake_case(text: str) -> str:
    return '_'.join(tokenize(text))

def to_camel_case(text: str) -> str:
    words = tokenize(text)
    return words[0] + ''.join(w.title() for w in words[1:])

def to_pascal_case(text: str) -> str:
    return ''.join(w.title() for w in tokenize(text))

def to_kebab_case(text: str) -> str:
    return '-'.join(tokenize(text))

def to_screaming_snake(text: str) -> str:
    return '_'.join(tokenize(text)).upper()

# Examples
print(to_snake_case("getUserByID"))     # get_user_by_id
print(to_camel_case("user_profile"))    # userProfile
print(to_pascal_case("my-css-class"))  # MyCssClass
print(to_kebab_case("MyClassName"))    # my-class-name
print(to_screaming_snake("apiBaseUrl"))# API_BASE_URL

JavaScript / TypeScript

function tokenize(str) {
  return str
    // camelCase / PascalCase → insert separator
    .replace(/([a-z0-9])([A-Z])/g, '$1_$2')
    .replace(/([A-Z]+)([A-Z][a-z])/g, '$1_$2')
    // split on separators
    .split(/[\s_\-]+/)
    .filter(Boolean)
    .map(w => w.toLowerCase());
}

function toKebabCase(str) {
  return tokenize(str).join('-');
}

function toCamelCase(str) {
  const words = tokenize(str);
  return words[0] + words.slice(1).map(w => w[0].toUpperCase() + w.slice(1)).join('');
}

function toPascalCase(str) {
  return tokenize(str).map(w => w[0].toUpperCase() + w.slice(1)).join('');
}

function toSnakeCase(str) {
  return tokenize(str).join('_');
}

function toScreamingSnake(str) {
  return tokenize(str).join('_').toUpperCase();
}

// Examples
console.log(toKebabCase('MyBackgroundColor'));  // my-background-color
console.log(toCamelCase('user_profile_page'));  // userProfilePage
console.log(toPascalCase('get-user-by-id'));    // GetUserById
console.log(toScreamingSnake('apiBaseUrl'));     // API_BASE_URL

Go

package main

import (
    "strings"
    "unicode"
)

// tokenize splits any casing into lowercase tokens
func tokenize(s string) []string {
    var words []string
    var current strings.Builder

    runes := []rune(s)
    for i, r := range runes {
        if r == '_' || r == '-' || r == ' ' {
            if current.Len() > 0 {
                words = append(words, strings.ToLower(current.String()))
                current.Reset()
            }
            continue
        }
        if unicode.IsUpper(r) && current.Len() > 0 {
            // Check for acronym: XMLParser → XML, Parser
            if i+1 < len(runes) && unicode.IsLower(runes[i+1]) {
                words = append(words, strings.ToLower(current.String()))
                current.Reset()
            }
        }
        current.WriteRune(r)
    }
    if current.Len() > 0 {
        words = append(words, strings.ToLower(current.String()))
    }
    return words
}

func ToCamelCase(s string) string {
    words := tokenize(s)
    if len(words) == 0 {
        return ""
    }
    result := words[0]
    for _, w := range words[1:] {
        result += strings.Title(w)
    }
    return result
}

func ToSnakeCase(s string) string {
    return strings.Join(tokenize(s), "_")
}

Use Cases

API Design and Documentation

When designing a REST API, consistency between your URL slugs (kebab-case), JSON payload keys (camelCase in JavaScript ecosystems, snake_case in Python), and database columns (snake_case) is critical. A case converter lets you quickly translate between these layers without error.

Example workflow:

  • Database column: user_created_at
  • JSON API response: userCreatedAt
  • URL parameter: user-created-at (rare, but used in some systems)
  • Constant reference: USER_CREATED_AT

Database Schema Migrations

When migrating between ORMs or database engines, column naming conventions often differ. ActiveRecord (Ruby on Rails) favours snake_case; some legacy systems used PascalCase or even camelCase for column names. A batch case conversion saves hours of tedious find-and-replace work.

Code Refactoring

Large codebases sometimes accumulate inconsistent naming from different eras or contributors. A case converter can assist during refactoring sprints — paste a list of identifiers, convert them all to the target convention, and apply with your IDE's rename tool.

Content Management Systems

URL slugs, taxonomy slugs, and tag names in CMSs need to be consistent. Converting "My Article Title" to my-article-title (kebab-case) or my_article_title (snake_case) is a daily operation for content engineers.


Manual Regex vs. Libraries

For most production code, you should reach for a battle-tested library rather than writing your own tokeniser:

JavaScript / TypeScript: change-case

import { camelCase, snakeCase, pascalCase, kebabCase } from 'change-case';

camelCase('user_profile_page');  // 'userProfilePage'
snakeCase('getUserById');        // 'get_user_by_id'
pascalCase('my-css-class');      // 'MyCssClass'
kebabCase('MyBackgroundColor');  // 'my-background-color'

change-case handles Unicode, acronyms, numbers, and edge cases that naive regex implementations miss.

JavaScript: Lodash

import _ from 'lodash';

_.camelCase('Foo Bar');       // 'fooBar'
_.snakeCase('fooBar');        // 'foo_bar'
_.kebabCase('fooBar');        // 'foo-bar'
_.startCase('--foo-bar--');   // 'Foo Bar'

Lodash is already in most JavaScript projects, making it a zero-cost option.

Python: inflection

import inflection

inflection.camelize('device_type')       # 'DeviceType' (PascalCase)
inflection.camelize('device_type', False)# 'deviceType' (camelCase)
inflection.underscore('DeviceType')      # 'device_type'
inflection.dasherize('device_type')      # 'device-type'

Python: stringcase

from stringcase import camelcase, snakecase, pascalcase

camelcase('foo_bar_baz')   # 'fooBarBaz'
snakecase('FooBarBaz')     # 'foo_bar_baz'
pascalcase('foo-bar-baz')  # 'FooBarBaz'

When to use a library vs. write your own: Libraries win in production (edge cases, maintenance, Unicode support). Roll your own only when you need a specific behaviour not offered by existing libraries, or in restricted environments where dependencies are problematic.


Best Practices

1. Consistency Over Personal Preference

The best naming convention for your project is the one your entire team uses uniformly. Mixing snake_case and camelCase in the same codebase is worse than using either one exclusively.

2. Automate with Linters

Don't rely on humans to remember conventions. Automate:

  • ESLint with @typescript-eslint/naming-convention rule
  • flake8 with pep8-naming plugin
  • golangci-lint with revive linter
  • RuboCop for Ruby naming conventions

3. .editorconfig for Cross-Editor Consistency

Use .editorconfig to enforce low-level formatting rules that feed into casing tools:

[*.py]
indent_style = space
indent_size = 4

[*.js]
indent_style = space
indent_size = 2

4. Document Your Conventions

Add a section to your project's CONTRIBUTING.md specifying which naming convention applies to each identifier type. New contributors will thank you.

5. Respect Language Idioms

Don't impose external conventions on a language. Using camelCase in Python because "the rest of the stack uses it" is an antipattern — it fights the language's tooling, documentation generators, and the expectations of every Python developer you'll ever hire.

6. Handle Acronyms Consistently

This is the most common source of inconsistency. Choose one approach and document it:

  • XMLParser vs XmlParser vs xmlParser
  • userID vs userId vs user_id
  • Google's Go style guide prefers userID and xmlParser; most JS style guides prefer userId and xmlParser.

Frequently Asked Questions

Q: Is there a difference between PascalCase and UpperCamelCase? No — they are the same convention. "PascalCase" is the more common term in the developer community; "UpperCamelCase" is used to distinguish it from regular camelCase (sometimes called lowerCamelCase) in academic or formal documentation.

Q: Why can't I use kebab-case for variable names in JavaScript? Because the hyphen - is the subtraction operator in JavaScript (and most C-family languages). The expression my-variable is parsed as my minus variable, not as a single identifier. Languages designed for configuration (YAML, TOML, CSS) don't have this restriction.

Q: Does the case converter handle Unicode and non-ASCII characters? Robust implementations do. Simple regex-based approaches may treat accented characters (é, ü, ñ) as word boundaries or lose their capitalisation. Libraries like change-case for JavaScript handle common Unicode cases correctly.

Q: What is the correct case for React component file names? The React community uses PascalCase for both the component name and file name: UserProfileCard.tsx. This distinguishes component files from utility files (utils.ts, api-client.ts) at a glance.

Q: How should I handle numbers in identifiers? Convention varies. Most tokenisers treat a digit sequence as its own token. base64Encoderbase64, Encoderbase64_encoder in snake_case. Make sure your tokeniser handles this consistently, especially for common terms like md5, sha256, oauth2.

Q: Should database column names use snake_case even if my app uses camelCase? Almost always yes. SQL is case-insensitive in most databases, and firstName could be interpreted differently by different tools. snake_case is the universal SQL convention and is understood by every ORM. Map to camelCase at the application layer.

Q: What case should I use for environment variables? SCREAMING_SNAKE_CASE is the universal standard for environment variables: DATABASE_URL, JWT_SECRET, PORT. This convention is followed by twelve-factor app methodology, Docker, Kubernetes, and virtually every deployment platform.

Q: Can I mix case conventions within a single identifier? No — this always indicates an error. Identifiers like myVariable_Name or My-ClassName are malformed and should be corrected. The only exception is when a prefix or suffix follows a different convention (e.g., __dunder__ in Python or _SCREAMING for module-level private constants, both of which are intentional by convention).

Overview

Text formatting is a fundamental part of coding and writing. Our Case Converter is a high-performance utility designed to help users transform the casing of their text instantly. Whether you need to fix a "CAPS LOCK" mistake or convert a variable name for a different programming language, our tool provides a comprehensive suite of options to get the job done without manual retyping.

Key Features

  • Multiple Case Modes: Supports UPPERCASE, lowercase, Sentence case, Title Case, camelCase, PascalCase, snake_case, and kebab-case.
  • Live Transformation: Watch your text change in real-time as you type or paste.
  • Clean Interface: Designed for speed with one-click copy and clear buttons.
  • Universal Compatibility: Works with any UTF-8 text, supporting special characters and diverse languages.

How to Use

  1. Paste Text: Enter the text you wish to transform into the input box.
  2. Choose Mode: Select the desired casing format from the menu.
  3. Refine: Toggle options like "Remove extra spaces" if available.
  4. Copy: Click the copy button to grab your newly formatted text.

Common Use Cases

  • Coding & Scripting: Quickly convert variable_names to camelCase or UPPER_SNAKE_CASE for different conventions.
  • Content Editing: Fix accidentally capitalized sentences or format titles for blog posts.
  • Database Management: Standardize field names or entry values during data cleaning.
  • Social Media: Create stylized text for posts and bios.

Technical Background

The tool uses specialized Regular Expressions (Regex) to identify word boundaries and apply transformation logic. For example, to convert to camelCase, the algorithm identifies spaces, underscores, and hyphens, removes them, and capitalizes the first letter of subsequent words.

Frequently Asked Questions

  • Is it safe? Yes, all transformations occur in your browser; we never store your text.
  • Does it support large text? Yes, it can handle thousands of words instantly.
  • Can I undo? Use the browser's standard CMD/CTRL+Z or simply change the mode again.

Limitations

  • Contextual Nuance: Sentence case might not always recognize proper nouns correctly.
  • Acronyms: Transforming to Title Case may lower-case some acronyms depending on the algorithm.
  • Complex Symbols: Non-alphanumeric characters are generally preserved but might affect boundary detection.