UUsefulCrate Your files never leave your browser

Home › Blog › Developer

Text Case Converter: When to Use Which Case

Case conventions are chosen by the destination, not by taste. Here is which one to copy, where it belongs, and how to keep an API key, a CSS class and a UI label from drifting apart.

2026-11-06 · 7 min read

Case conventions are not decoration: each one belongs to a particular context, and using the wrong one can break a build, a URL or a database query. A case converter gives you ten variants of the same phrase at once, but the useful skill is knowing which of those ten to copy. This guide maps the common conventions to where they are actually used, then shows a workflow for standardising names across a project without introducing typos.

The conventions and where they belong

ConventionExampleUsed for
camelCaseuserProfileNameJavaScript variables and object keys
PascalCaseUserProfileNameClasses, types, React components
snake_caseuser_profile_namePython, Ruby, database columns
kebab-caseuser-profile-nameCSS classes, URLs, file names
CONSTANT_CASEUSER_PROFILE_NAMEEnvironment variables, constants
Sentence caseUser profile nameUI labels, button text
Title CaseUser Profile NameHeadings, article titles
lowercaseuser profile nameSlugs, tags, normalised input

The Case Converter produces all of these from one pasted phrase, which matters less for speed than for consistency: every variant comes from the same source string, so a field name in the API, the CSS class on the card and the label shown to a user cannot drift into three slightly different spellings.

Why the convention is chosen by the destination

A name is not inherently camelCase or snake_case. It takes that shape because the language or system reading it expects it. JavaScript object keys are conventionally camelCase, so shipping snake_case there makes a codebase look like two projects glued together. Python style guides prefer snake_case. CSS is case-sensitive in some contexts and hyphens read clearly, so kebab-case won. URLs are lower-cased by many servers and hyphens are treated as word separators by search engines, which is why a slug is not a sentence.

There is a harder reason too: some destinations are case-sensitive. A Linux filesystem treats Invoice.pdf and invoice.pdf as two different files. A database column created as userName will not be found by a query written as username on a case-sensitive collation. Picking a convention and applying it everywhere is a correctness issue, not a taste one.

A practical workflow for naming a feature

Suppose you are adding a shipping address field to a small web app. Rather than typing the name five times, do this:

  1. Write the phrase once in plain English. Type customer shipping address into the Case Converter.
  2. Take the API key from camelCase. customerShippingAddress goes into the JSON response and the JavaScript object.
  3. Take the database column from snake_case. customer_shipping_address matches the SQL schema.
  4. Take the CSS class and the route from kebab-case. customer-shipping-address works for both, and the Slug Generator can produce a matching URL path from the same phrase.
  5. Take the label from sentence case. Customer shipping address is what the user reads. A label should not look like an identifier.
  6. Record the mapping. Keep the four chosen strings in a short comment or a schema note so the next person does not invent a fifth spelling.

Six steps, one source phrase, zero opportunities to type shippingAdress into the API and shipping_address into the client. That typo is the kind that survives code review and only appears when a form submits an empty field.

Where converters get tricky

Acronyms

A converter segments words rather than understanding them, so API, URL or ID may be split into individual letters in some formats. apiKeyUrl and APIKeyURL are both defensible, and different style guides pick different ones. Copy the generated value and adjust that one token by hand to match the codebase you are in.

Punctuation and accents

Apostrophes, ampersands and accented characters are treated as word boundaries or normalised. That is usually what you want for an identifier, but it means a phrase such as user's profile becomes something like userSProfile or user-s-profile depending on the format. Read the output before pasting it into production code.

Already-formatted input

Pasting user_profile-name is fine: existing separators are treated as boundaries and the phrase is rebuilt in each convention. This makes the tool useful for cleaning up legacy identifiers where three naming styles have accumulated in one file.

Standardising an existing messy list

For a codebase or a spreadsheet with dozens of inconsistent field names, a single pass is faster than editing each one:

  1. Paste the whole column into the Text Cleaner and remove blank lines, duplicates and trailing whitespace.
  2. Convert each name to the convention you have chosen, one phrase at a time, or apply a rule with the Find & Replace tool for a systematic prefix or suffix change.
  3. Put the old and new columns side by side in the Text Diff tool and read every changed line.
  4. Search the codebase for the old spelling before renaming anything, since a field name may appear in templates, tests, documentation and a saved query.

Renaming a field that is already live in an API is a migration, not a formatting exercise. Publish the new name alongside the old one for a transition period, then retire the old one once every client has moved.

Case is not the same as meaning

A converter changes the shape of a string; it does not translate it, pluralise it or disambiguate it. address may mean a postal address, an email address or a memory address, and no case convention will tell you which. Abbreviations are another trap: shortening customer shipping address to csa saves typing and costs every future reader clarity. Keep names descriptive and let the converter handle only the formatting.

Common questions

Which case should I use for a URL?

Lower case with hyphens between words. The Slug Generator produces exactly that from a headline, and it also removes punctuation and accents so the path stays readable and portable.

Does the converter change my data or just the display?

It produces new strings for you to copy; it does not touch any file or database. You decide where each result goes, which is why checking the destination's convention first matters.

Why are there ten formats when I only need one?

Because a single feature usually needs several. Seeing the whole set at once makes it easy to keep the API key, the CSS class, the database column and the visible label derived from one phrase rather than four independent typings.

Tools on this site

Case Converter produces every common convention from one phrase. Slug Generator turns a title into a URL-safe path. Text Diff verifies a bulk standardisation before anything is changed.

← All posts