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
| Convention | Example | Used for |
|---|---|---|
| camelCase | userProfileName | JavaScript variables and object keys |
| PascalCase | UserProfileName | Classes, types, React components |
| snake_case | user_profile_name | Python, Ruby, database columns |
| kebab-case | user-profile-name | CSS classes, URLs, file names |
| CONSTANT_CASE | USER_PROFILE_NAME | Environment variables, constants |
| Sentence case | User profile name | UI labels, button text |
| Title Case | User Profile Name | Headings, article titles |
| lowercase | user profile name | Slugs, 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:
- Write the phrase once in plain English. Type
customer shipping addressinto the Case Converter. - Take the API key from camelCase.
customerShippingAddressgoes into the JSON response and the JavaScript object. - Take the database column from snake_case.
customer_shipping_addressmatches the SQL schema. - Take the CSS class and the route from kebab-case.
customer-shipping-addressworks for both, and the Slug Generator can produce a matching URL path from the same phrase. - Take the label from sentence case.
Customer shipping addressis what the user reads. A label should not look like an identifier. - 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:
- Paste the whole column into the Text Cleaner and remove blank lines, duplicates and trailing whitespace.
- 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.
- Put the old and new columns side by side in the Text Diff tool and read every changed line.
- 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.