Paste any text and convert it to nine case formats in real time — no button to click, nothing sent to a server. This page also serves as a naming-convention reference: which format to use in which language, the rules each style guide actually disagrees on, and the mistakes that get caught in code review.

The Nine Cases

Case	Example	Typical Uses
UPPERCASE	HELLO WORLD	Constants, SQL keywords, acronyms, short UI labels
lowercase	hello world	Emails, URLs, CSS values, normalizing input
Title Case	Hello World	Article titles, book titles, formal headings
Sentence case	Hello world	Body copy, UI labels, notifications, email subjects
camelCase	helloWorld	JS/TS variables, JSON keys, Java methods, React props
PascalCase	HelloWorld	Class names, TypeScript types, React/Vue components
snake_case	hello_world	Python variables, database columns, Ruby methods
kebab-case	hello-world	CSS classes, HTML attributes, URL slugs, npm packages
CONSTANT_CASE	HELLO_WORLD	Constants and environment variables in all languages

How to Use

1. Paste or type text into the input field — conversion happens in real time.
2. Select a case from the radio buttons.
3. Use Upload to load a .txt file, Clear to reset both fields, Copy or Download to take the result.

Which Case Should I Use?

The fastest answer by context:

For code:

If you are naming…	Use
Variable or function in JS, TS, Java, Swift, Kotlin	camelCase
Variable or function in Python, Ruby, Rust	snake_case
Class, type, interface, or component (any language)	PascalCase
Constant or environment variable	CONSTANT_CASE
CSS class or HTML data- attribute	kebab-case
URL path segment or slug	kebab-case
Database column or table name	snake_case
npm or pip package name	kebab-case
JSON object key in a REST API	camelCase
Go exported identifier (public)	PascalCase
Go unexported identifier (package-private)	camelCase

For written content:

Context	Use	Note
News headline, book title, formal publication	Title Case	Style guide rules vary — see section below
Blog post title, product UI label, app notification	Sentence case	Matches how people type search queries
Button label in a space-constrained UI	UPPERCASE	Use sparingly
Email subject line	Sentence case	All-Title-Case subjects correlate with lower open rates
Multi-word hashtag	PascalCase	#ContentMarketing scans faster than #contentmarketing

Naming Conventions by Programming Language

Language	Variable / Function	Class / Type	Constant	File name
JavaScript	camelCase	PascalCase	CONSTANT_CASE	kebab-case
TypeScript	camelCase	PascalCase	CONSTANT_CASE	kebab-case
Python	snake_case	PascalCase	CONSTANT_CASE	snake_case
Java	camelCase	PascalCase	CONSTANT_CASE	PascalCase
Go	camelCase / PascalCase*	PascalCase	PascalCase	snake_case
Rust	snake_case	PascalCase	CONSTANT_CASE	snake_case
Ruby	snake_case	PascalCase	CONSTANT_CASE	snake_case
C#	camelCase / PascalCase†	PascalCase	PascalCase	PascalCase
PHP	camelCase	PascalCase	CONSTANT_CASE	snake_case
Swift	camelCase	PascalCase	camelCase‡	PascalCase
SQL columns	snake_case	—	—	—
CSS classes	kebab-case	—	—	—
URL slugs	kebab-case	—	—	—
npm / pip packages	kebab-case	—	—	—
ENV variables	—	—	CONSTANT_CASE	—
JSON keys (REST)	camelCase	—	—	—

* Go: capitalization controls export visibility. PascalCase = exported (public); camelCase = unexported (package-private). This is enforced by the compiler, not just convention.

† C#: local variables and parameters use camelCase; methods, properties, and public fields use PascalCase.

‡ Swift: constants use camelCase — let maxRetries = 3 is idiomatic; let MAX_RETRIES = 3 is not.

When to Use Each Case

camelCase

camelCase emerged from SIMULA and early object-oriented languages in the 1960s, reached mainstream adoption through Java (1995), and spread to JavaScript, TypeScript, Swift, and Kotlin. The rule is simple: first word stays entirely lowercase, every subsequent word starts with a capital, no separator character.

The case is dominant in any ecosystem where Java set the early conventions. Node.js core APIs (readFile, createServer, writeFileSync), React event props (onClick, onChange, defaultValue), and REST JSON keys (userId, createdAt, isActive) all follow it. ESLint enforces it in JavaScript projects via the built-in camelcase rule.

// React
const [isLoading, setIsLoading] = useState(false);
const handleSubmit = (event) => { ... };

// Node.js
fs.readFile(filePath, 'utf8', callback);
http.createServer(requestListener);

When not to use it: Never in URL paths — many servers are case-insensitive and UserOrders and userorders become the same route. Never in Python or Ruby files (PEP 8 and the Ruby Style Guide both flag it). Never for class names in any language — that is PascalCase territory.

PascalCase

PascalCase takes its name from the Pascal language (Niklaus Wirth, 1970), though Borland and Delphi tools spread it as the class-naming standard in the 1990s. Every word — including the first — starts with a capital. That single difference from camelCase carries semantic weight: PascalCase says “this is a thing you instantiate or a type you reference,” not “this is an action you call.”

The pattern is universal for class names across all major OOP languages. In TypeScript it extends to interfaces and type aliases. In React and Vue it is required for component names — the framework uses capitalization to distinguish user-defined components (UserProfile) from HTML elements (div, input). In C#, PascalCase covers methods and public properties in addition to class names.

// React component
export default function UserProfileCard({ userId }) { ... }

// TypeScript
interface ApiResponse<T> {
  data: T;
  totalCount: number;
  nextCursor: string | null;
}

// Python
class DatabaseConnection:
    def __init__(self, url: str) -> None: ...

When not to use it: Never for variables or regular functions in JavaScript, TypeScript, or Python. A PascalCase function in JS implies it is a constructor meant to be called with new — using it for a plain utility function misleads other developers and may trigger lint warnings.

snake_case

snake_case has roots in C library function names (printf, fopen, strcmp) and Unix shell scripting. Python’s PEP 8 (written by Guido van Rossum in 2001) formalized it for the language with this rationale: words_separated_by_underscores reads more like English prose than compressed camelCase, making code accessible to domain experts who are not primarily programmers.

It is the universal standard for relational database identifiers — SQL is case-insensitive by default, so UserProfile and userprofile are the same column, and snake_case makes columns readable without depending on capitalization. Django’s ORM, Rails migrations, and virtually every database migration tool generate snake_case column names.

# Django model
class UserProfile(models.Model):
    first_name = models.CharField(max_length=100)
    created_at = models.DateTimeField(auto_now_add=True)
    is_active = models.BooleanField(default=True)

def get_user_by_id(user_id: int) -> UserProfile:
    return UserProfile.objects.get(pk=user_id)

When not to use it: Never in URL paths — underscores are not visible when URLs are underlined in browsers and may be stripped by some link processors. snake_case is technically valid in JavaScript identifiers but breaks ESLint’s camelcase rule and signals to every JS developer that the author was thinking in Python.

kebab-case

kebab-case is defined by lowercase words joined with hyphens. CSS adopted it as the standard for all property names — background-color, font-size, border-radius, flex-direction — and the convention spread to HTML attributes, URL slugs, and npm packages. The hyphen is uniquely suited to web contexts because it is never a valid identifier character in most programming languages, which is also exactly why it cannot be used for code variables.

The SEO case for kebab-case URLs is well-established: Google treats hyphens as word separators in URLs but does not treat underscores the same way. A URL like /blog/user-profile-guide is indexed with “user,” “profile,” and “guide” as distinct searchable terms. /blog/user_profile_guide is indexed as a single token. For any publicly visible URL, kebab-case is the only choice with SEO benefit. Google’s John Mueller has confirmed this distinction repeatedly in public Q&As.

/* CSS */
.nav-item { ... }
.card-header { ... }
.btn-primary { ... }

<!-- HTML -->
<div data-user-id="123" data-tracking-event="page-view">

/* npm */
react-router, tailwind-css, lodash, date-fns

When not to use it: Never for code variables or functions. In every C-style language, a hyphen is the subtraction operator — my-variable parses as my minus variable.

CONSTANT_CASE

CONSTANT_CASE originates in C preprocessor macros from the 1970s (#define MAX_BUFFER_SIZE 1024). The all-caps-with-underscores pattern became the universal signal for “this value is fixed at compile time or configuration time and must not change at runtime.” Every major language adopted the pattern; .env files and shell scripts extended it to deployment configuration.

The visual loudness of ALL_CAPS serves a real function: it tells the reader at a glance that this is configuration, not logic — a fixed boundary condition, not a computed value. That signal is worth preserving, which is why using CONSTANT_CASE for mutable values or function names is a genuine mistake (see the section below).

# Environment variables (.env)
DATABASE_URL=postgresql://localhost/mydb
STRIPE_API_KEY=sk_live_...
MAX_UPLOAD_SIZE_MB=10
JWT_SECRET_KEY=...

// JavaScript module constants
const MAX_RETRIES = 3;
const API_BASE_URL = 'https://api.example.com/v1';
const DEFAULT_TIMEOUT_MS = 5000;

When not to use it: Never for functions, methods, or variables that change at runtime. Never for class names. In Swift specifically, constants use camelCase — let maxRetries = 3 is idiomatic; the CONSTANT_CASE pattern is not used in Swift code.

Common Naming Mistakes

These are the errors that appear in code review, get flagged by linters, and make codebases harder to read for everyone who comes after.

Mixing conventions in the same project

The single most damaging naming mistake. A codebase where getUserById and get_order_history coexist forces readers to context-switch on every function call — they cannot predict whether the next function will be camelCase or snake_case. A project that consistently uses the “wrong” convention for its ecosystem is more readable than one that mixes “correct” ones. Pick one convention per context and enforce it with a linter from day one.

snake_case in JavaScript variable names

const user_profile = {} is valid JavaScript — the runtime does not care. But it signals to every JavaScript developer reading the code that the author comes from a Python or Ruby background. ESLint’s built-in camelcase rule flags it. If your team works across JS and Python files, the cross-contamination is common; resist it. snake_case stays in .py files, camelCase in .js and .ts files.

camelCase or snake_case in URL paths

/api/userOrders and /api/user_orders are both wrong. camelCase in URLs risks case-sensitivity bugs — Apache on Windows is case-insensitive, so /api/UserOrders and /api/userorders are the same route, but /api/userOrders on a Linux server is not. Underscores in URLs lose their word-separator meaning for search engines (see kebab-case section above). The correct form is /api/user-orders for every public-facing URL.

CONSTANT_CASE for non-constants

function GET_USER_BY_ID(id) {} uses a visual signal that means “this value never changes.” Applying it to a function, a computed property, or a mutable variable misleads every developer who reads the code later. Reserve CONSTANT_CASE strictly for values that are set at startup and never reassigned — module-level constants, environment variable reads, and compile-time configuration.

PascalCase for utility functions in JavaScript

function GetUserById(id) {} looks like a constructor in JavaScript. The convention that PascalCase = “call with new” is deeply ingrained in the ecosystem. A PascalCase function that is not a constructor will confuse readers and may trigger ESLint’s new-cap rule. Use camelCase for all functions and methods; reserve PascalCase for classes, types, and React components.

Names that require a comment to explain

usrPrf, ord, cfg, tmp2. Brevity is a virtue until it creates ambiguity — ord could be order, ordinal, or ordinary. Modern editors provide autocomplete; there is no real keystroke cost to userProfile. The test: if the name requires an inline comment to explain what it refers to, rename it instead.

Handling Acronyms in Variable Names

Acronyms like API, HTTP, URL, and ID create genuine ambiguity in camelCase and PascalCase. Should you write myAPIKey or myApiKey?

Treat acronyms as words (modern, recommended for new projects): myApiKey, HttpRequest, parseUrl, getUserById. This is the approach in TypeScript’s standard library and Google’s Java Style Guide. It is easier to scan and avoids the problem of adjacent acronyms — parseHtmlToXml is immediately readable where parseHTMLtoXML requires a double-take.

Preserve acronym caps (traditional): myAPIKey, HTTPRequest, parseURL. More common in older Java and C# codebases. Creates readability problems when two acronyms appear together.

For snake_case and CONSTANT_CASE the question disappears — api_key, http_request, API_KEY, HTTP_HOST are all unambiguous regardless of which school you follow.

Go’s special rule: two-letter acronyms stay fully capitalized (ID, DB, IP); longer acronyms are treated as words (Http, Url, Api). This is documented in the Go Code Review Comments guide.

The only rule that matters: pick one approach and apply it consistently across the entire codebase. Mixing myApiKey and myAPIKey in the same project is worse than either choice alone.

Title Case: Rules by Style Guide

Title Case capitalizes certain words in a heading or title. Four major style guides each define which words to capitalize — and they disagree on the edge cases.

Rule	AP Style	APA Style	Chicago Style	MLA Style
Capitalize first and last word	✓	✓	✓	✓
Capitalize nouns, verbs, adjectives, adverbs	✓	✓	✓	✓
Short prepositions (in, on, at, by, of, up)	Lowercase ≤3 letters	Lowercase ≤3 letters	Lowercase	Lowercase ALL
Coordinating conjunctions (and, but, or, nor)	Lowercase	Lowercase	Lowercase	Lowercase
Articles (a, an, the)	Lowercase	Lowercase	Lowercase	Lowercase
”to” as infinitive marker	Capitalize	Capitalize	Capitalize	Capitalize
”to” as preposition	Lowercase	Lowercase	Lowercase	Lowercase
Short verbs (is, are, was)	Capitalize	Capitalize	Capitalize	Capitalize

The same title across all four styles:

“A Guide to Writing for the Web and Social Media”

All four agree here. Disagreements appear with longer prepositions (“about,” “between,” “without”) and compound titles joined by a colon.

Words that stay lowercase in all four styles (unless opening or closing the title): a, an, the, and, but, or, nor, for, so, yet, as, at, by, in, of, on, to (preposition), up, via.

This converter capitalizes every word — the most common general-purpose behavior. For strict AP, APA, Chicago, or MLA compliance, use this tool for a first pass and apply manual corrections for the short words.

Pre-filling via URL Parameters

Pre-load input text and case type via URL:

https://www.uprek.com/en/tools/case-converter?input=Hello+World&case=snake

Available ?case= values: upper, lower, title, sentence, camel, pascal, snake, kebab, constant.

Privacy

All conversion runs in your browser using native JavaScript — String.toUpperCase(), String.toLowerCase(), String.replace(), and TextEncoder. Your text is never sent to our servers, never logged, and never stored. To verify: open your browser’s developer tools, go to the Network tab, paste text into the tool, and switch cases — you will see zero outbound network requests.

Frequently Asked Questions

Changelog