camelCase, snake_case, kebab-case: Naming Conventions and When to Convert

Naming looks like a style preference until data crosses a boundary — a JSON API into a Python backend, a database column into a JavaScript object, a CSS class into a component prop. Each side has a preferred casing, and the seams between them are a reliable source of "undefined is not a function." Knowing the conventions (and converting deliberately) saves a surprising amount of debugging.

The common cases

• camelCase — firstName. First word lowercase, subsequent words capitalized. The default in JavaScript, Java, and JSON payloads for many APIs.
• PascalCase (UpperCamelCase) — FirstName. Every word capitalized. Classes, types, and React components.
• snake_case — first_name. Words joined by underscores. Python, Ruby, SQL columns, and many REST APIs.
• kebab-case — first-name. Words joined by hyphens. URLs, CSS classes, HTML attributes, and file names. (Not valid as an identifier in most languages — you cannot name a variable first-name.)
• SCREAMING_SNAKE_CASE — FIRST_NAME. Constants and environment variables.

The Case Converter transforms text between all of these, which is handy when you are, say, turning a list of database columns into camelCase object keys or a heading into a URL slug.

Where the boundaries bite

The bugs almost always appear at a translation point:

• API ↔ backend. A JavaScript client sends firstName; a Python API expects first_name. If nothing maps between them, the field silently arrives as None. Decide on one convention at the boundary and convert consistently — many frameworks do this for you, but only if configured.
• Database ↔ code. SQL columns are usually snake_case; your ORM maps them to your language's convention. A hand-written query that returns user_id into code expecting userId will hand you undefined.
• Slugs and file names. Turning a title like "My First Post!" into a URL means kebab-case plus stripping punctuation: my-first-post. Get the casing right but forget to remove the ! and you have a broken link.

Convert deliberately, not by hand

Hand-editing casing across a long list is exactly the kind of tedious task that introduces typos — a missed capital, an underscore where a hyphen belongs. Two habits help:

1. Batch-convert a column list or a set of keys with the Case Converter rather than editing each by hand.
2. Normalize a list — dedupe and sort field names before converting — with the Line Sorter, so you are not converting the same key twice or missing one.

When you are mapping a payload's fields, the JSON Formatter makes it easy to read both sides side by side and confirm every key lines up after conversion.

A tiny checklist

When data crosses a boundary, ask:

• What casing does the source use, and what does the destination expect?
• Is there an automatic mapping, or am I responsible for converting?
• For slugs and file names: did I also strip punctuation and collapse spaces, not just change the case?

The short version

Casing is a dialect, and every ecosystem speaks its own. The trouble is not any single convention — it is the untranslated boundary between two of them. Pick the right case for each context (kebab for URLs and CSS, snake for Python and SQL, camel for JS and JSON), and convert in bulk with the Case Converter instead of trusting your fingers.