The Case Converter Field Guide: camelCase, snake_case, kebab-case, and the Acronyms That Break Them

Changing the case of a word sounds trivial. Then you try to turn parseHTTPResponse into snake_case and realize there is no single right answer, only a set of conventions different communities agreed on years ago. A good case converter doesn't just upper- or lower-case characters; it understands those conventions and the edge cases that hide inside them.

This guide walks through the five conventions you actually need, where each one belongs, and the three traps — acronyms, small words, and sentence boundaries — that make case conversion harder than a single toUpperCase() call.

The five conventions and where they belong

Each casing style carries meaning. Pick the wrong one and your code looks foreign to anyone reading it.

camelCase — first letter lowercase, every later word capitalized: userFirstName. The default for variables and functions in JavaScript, Java, and Swift.
PascalCase — like camelCase but the first letter is also capitalized: UserProfileCard. Reserved for classes, types, and React components.
snake_case — all lowercase, words joined by underscores: user_first_name. The standard for Python and Ruby, and the usual shape of SQL columns and JSON API fields.
kebab-case — all lowercase, words joined by hyphens: featured-product-card. CSS class names, URL slugs, and HTML attributes live here. (Underscores aren't valid in hyphenated identifiers the way kebab-case expects.)
CONSTANT_CASE — all uppercase with underscores: MAX_RETRY_COUNT. Reserved for constants and environment variables across nearly every language.

These aren't personal preferences. Python's PEP 8 states plainly that function and variable names should be lowercase with words separated by underscores, while class names use the "CapWords" (PascalCase) convention. The Google JavaScript Style Guide mandates camelCase for method and parameter names and PascalCase for class and enum names. When a converter respects these defaults, the output drops straight into a codebase without a reviewer flagging it.

A single sentence, seven ways

The fastest way to see the differences is to convert one phrase through every mode. Take the label "Featured Product Card":

| Mode | Output | |---|---| | camelCase | featuredProductCard | | PascalCase | FeaturedProductCard | | snake_case | featured_product_card | | kebab-case | featured-product-card | | CONSTANT_CASE | FEATURED_PRODUCT_CARD | | Title Case | Featured Product Card | | Sentence case | Featured product card |

One paste, and you get the CSS class (featured-product-card), the React component name (FeaturedProductCard), and the env key (FEATURED_PRODUCT_CARD) without retyping the words three times and introducing a typo on the second pass.

Trap one: acronyms that refuse to split cleanly

The hardest input in case conversion is the embedded acronym. Consider parseHTTPResponse. A naive converter that inserts a break before every capital letter produces parse_h_t_t_p_response — which is nonsense. The acronym HTTP should stay whole.

The right behavior is to detect the boundary between a run of capitals and the next word. So parseHTTPResponse becomes parse_http_response in snake_case and parse-http-response in kebab-case, with HTTP collapsed into one token rather than four lonely letters. The converter looks for the transition where the last capital of a run actually belongs to the next word (the R in Response here) and splits there.

This matches how style guides treat acronyms. Google's guide explicitly recommends treating acronyms as words — loadHttpUrl, not loadHTTPURL — precisely because tooling and humans both read the word form more reliably. If you genuinely need each letter separated, the trick is to add spaces in your input first; no converter can guess that IO means "I O" rather than "input/output".

Trap two: Title Case is not "capitalize every word"

Title Case looks simple until you hit small words. The convention — from the Chicago and AP style traditions — is that articles, short conjunctions, and short prepositions stay lowercase unless they start or end the title. So the shouty submission 10 WAYS TO SPEED UP YOUR SITE should become:

10 Ways to Speed up Your Site

Note that to stays lowercase and up stays lowercase (it's a preposition here), but Ways, Speed, Your, and Site are capitalized. A converter that blindly upper-cases the first letter of every token would give you 10 Ways To Speed Up Your Site, which reads as overcorrected. If you're cleaning headlines for a blog or a word counter pass before publishing, this distinction is the difference between editorial polish and amateur output.

Trap three: sentences masquerading as identifiers

The last trap is structural, not lexical. People paste a whole sentence and expect one identifier per line. Run CONSTANT_CASE on a b. c d and you get a single token, A_B_C_D, because the converter treats the period as just another separator and joins everything into one identifier.

The fix is to split your input into separate lines first — one identifier per line. Then a list of eight loose phrases like "max retry count", "api base url", and "enable beta flag" becomes a clean column of MAX_RETRY_COUNT, API_BASE_URL, and ENABLE_BETA_FLAG, each on its own row, ready to drop into a .env file. The same line-per-token discipline matters when you feed names into a slug generator for URLs, since one stray sentence collapses into one very long slug.

How I actually use it day to day

I reach for case conversion most when a backend and a frontend disagree about naming. An API returns user_first_name, user_last_name, and created_at in snake_case, but my React state wants camelCase. Before I built this into my workflow, I'd hand-retype each key and inevitably fat-finger one of them — craetedAt is a classic, and it fails silently until a component renders undefined. Now I paste all twelve field names at once, switch to camelCase, and copy the block back. Twelve keys, zero typos, about four seconds. The pasted text never leaves the browser, so I don't think twice about field names from an unreleased feature.

A short decision checklist

When you're unsure which case to use, the language usually decides for you:

Writing a JS/Java variable or function? camelCase.
Naming a class, type, or React component? PascalCase.
Python or Ruby identifier, or a SQL/JSON field? snake_case.
CSS class, URL slug, or HTML attribute? kebab-case.
A constant or environment variable? CONSTANT_CASE.
A headline or heading? Title Case — and let the small words stay small.

Get the convention right and the output reads native to whoever opens the file next. That's the whole job of a case converter: not changing letters, but changing them the way your language already expects.

Made by Toolora · Updated 2026-06-13