Case Converter

Paste any text and get all nine common casings at once — UPPERCASE, lowercase, Title Case, Sentence case, camelCase, PascalCase, snake_case, kebab-case and CONSTANT_CASE. Click a result to copy it.

What Is a Case Converter?

A case converter rewrites a piece of text in a different letter casing convention. That sounds trivial until you need the same phrase in five forms at once: a database column wants user_profile_settings, the REST API it feeds wants userProfileSettings, the CSS class wants user-profile-settings, the env variable wants USER_PROFILE_SETTINGS, and the page heading wants "User Profile Settings". Doing that by hand is where typos and copy-paste bugs come from.

The Nine Casings and Where Each One Belongs

• camelCase — JavaScript and TypeScript variables, JSON keys, Java methods, API field names.
• PascalCase — class and type names in JS/TypeScript, C#, Java, Go exported identifiers, React components.
• snake_case — Python and Ruby variables and functions, PostgreSQL/SQL column names, Rust locals.
• kebab-case — CSS class names, HTML attributes, URL slugs, npm package names, custom elements in the DOM.
• CONSTANT_CASE — environment variables, Go constants, C/C++ macros, feature-flag keys.
• Title Case / Sentence case — page headings, email subject lines, UI button and menu labels.

Why Naive Conversion Breaks

Every case converter has to decide where one word ends and the next begins, and English does not make that easy. Notes like "iPhone" and "McDonald's" are already cased in a way no rule reproduces; acronyms are worse, since parse_HTTP_response could legitimately become parseHttpResponse or parseHTTPResponse. The pragmatic rule most codebases settle on is: acronyms become regular words in camelCase/PascalCase (parseHttpResponse, HttpClient) and stay whole in CONSTANT_CASE. Tools above collapse runs of separators (_, -, multiple spaces) into a single word boundary, so pasting a snake_case identifier and asking for kebab-case gives exactly what you expect.

Pro Tips

• Convert identifiers straight from code. Paste getUserProfileById and you get get_user_profile_by_id — faster and less error-prone than retyping, and it avoids the classic mismatched-pair bug where a JSON key drifts from its database column.
• Keep one canonical spelling. Whatever casing you pick, apply it everywhere: a field named user_id in Postgres, userId in JSON and USER_ID in the env file is fine — user_Id somewhere in the middle is not.
• Remember that databases fold case silently. PostgreSQL lowercases every unquoted identifier, so CREATE TABLE UserSettings actually creates usersettings — and SELECT * FROM UserSettings keeps working only because the query is folded the same way. MySQL hides the bug better: table names are case-sensitive on Linux and case-insensitive on Windows and macOS, so a query that runs fine on your laptop can fail in production. Choose lowercase snake_case for schema names and the problem never appears.
• Locale-aware casing exists for a reason. In Turkish, 'i'.toLocaleUpperCase('tr') is İ (dotted capital I), while the plain toUpperCase() gives I. JavaScript's toUpperCase() is locale-independent, so it will not surprise you here — but server code that lowercases user input per locale can, and lowercase-then-compare checks on tags like INFO have caused real auth bugs.

FAQ

Q: Is my text sent to a server?

No. The conversion runs entirely in your browser with JavaScript, so it is safe for private copy, unpublished product names and internal identifiers.

Q: How does it know where words start in an identifier?

It splits on three signals at once: separators (_, -, spaces), lowercase-to-uppercase transitions (userProfile → user | profile), and acronym-to-word transitions (HTTPClient → HTTP | Client). That is why getUserProfileById, get_user_profile_by_id and get-user-profile-by-id all produce the same nine outputs.

Q: Why does "iPhone" or "McDonald" come out wrong in Title Case?

Because Title Case only has a rule for the first letter of each word, and those names carry meaning in their internal capitals — it produces Iphone and Mcdonald. Run the conversion, then fix the handful of proper nouns by hand; a keep-list of brand names is the usual production fix.

Q: Why do Title Case rules differ between style guides?

Because guides disagree about minor words. AP and Chicago capitalise everything except articles, coordinating conjunctions and short prepositions, so "How to Format Dates in Python" and "How to Format Dates In Python" are both defensible. This tool capitalises every word — the predictable choice for headings and UI labels — so lowercase to, in and of yourself if your style guide requires it.

Q: Should my API use camelCase or snake_case?

Pick one and never mix them in the same payload. JSON APIs built in JavaScript ecosystems usually use camelCase, Python and Ruby backends usually use snake_case, and both are correct — consistency matters far more than the choice, because a mixed payload (userId next to created_at) forces every client to special-case field names.

Q: Can I convert a whole file or a list of identifiers?

One paste at a time here — but you can convert a full column name list in one go, then run the outputs through the Diff Checker against the old list to confirm nothing but casing changed. For scripted bulk renames, sed or a small Python re.sub that mirrors the same three split rules is the right tool.

Q: Can converting case change the length of my text?

Yes, and it catches people out. In Unicode, case mapping is not always one character to one character: German ß uppercases to SS, the ligature fi becomes FI, and Turkish lowercase i uppercases to İ with toLocaleUpperCase('tr'). If you sized a fixed-width CHAR(n) column or a fixed byte buffer for the original string, upper-casing user input can overflow it — measure the converted string, not the one you started with.

Q: Is case conversion the same in every language?

No — the Turkish dotless i is the classic trap. In Turkish, i uppercases to İ and I lowercases to ı, so a check like 'INFO'.toLowerCase() === 'info' is safe in JavaScript (locale-independent by default) but not in code that lowercases input according to the user's locale. The safe habit is to make case-insensitive comparisons at the storage layer — a case-insensitive collation, or a dedicated lowercased index column — instead of assuming every client will normalise the same way.

Q: Does case change how my database sorts rows?

Yes, and it is the collation — not the casing — that decides. In MySQL utf8mb4_0900_ai_ci and PostgreSQL's default en_US.UTF-8 sort case-insensitively, so alpha, Beta and ALPHA interleave; a _bin or C collation sorts by code point, which puts every uppercase letter before every lowercase one (Zebra before alpha). Two consequences: a paginated list can look "randomly" ordered when the collation and the index disagree, and ORDER BY on a case-sensitive column will never match the alphabetical order users expect. Pick the collation deliberately, and if you need case-insensitive lookups on a case-sensitive column, index LOWER(name) rather than lowercasing the stored value.

Q: Why do my env vars work locally and fail in Docker?

Because environment variable names are case-insensitive on Windows and case-sensitive on Linux and macOS. A key written as Max_Connections resolves on a Windows dev box and becomes a different, missing variable inside a Linux container, so the app silently falls back to the default. The same class of bug hits config keys parsed by different libraries — YAML and JSON keep case, some INI parsers do not. Adopt SCREAMING_SNAKE_CASE for env keys, spell them identically in every .env, compose file and CI secret, and validate at boot by asserting the required keys exist instead of trusting the fallback.

Why Use Our Case Converter?

Nine casings at once, no signup, no uploads, no clicking through one conversion at a time. Every result updates as you type and copies to your clipboard with a single click, so moving an identifier from a database column to a JSON key to an env variable takes seconds instead of retyping.