How to Convert Identifiers Between Naming Styles

You’re mapping a database table to an API response. The columns are user_first_name and created_at; the JSON needs userFirstName and createdAt. There are forty of them, and you’re about to do it by hand because writing the regex feels like more work than the typing.

Twenty minutes later you’ve got thirty-eight correct conversions, one typo you won’t find until a test fails, and HTTPResponseCode turned into something nobody agrees on.

What case conversion actually involves

Converting between naming styles is two steps: split the identifier into words, then rejoin them in the target style.

The rejoining is trivial. The splitting is where every implementation differs, because the word boundaries aren’t always marked. user_first_name splits on underscores — easy. userFirstName splits on the capital letters — still easy. HTTPResponseCode has no unambiguous answer at all.

Is that HTTP + Response + Code, or H + T + T + P + Response + Code? Both are defensible. One gives you http_response_code, the other gives h_t_t_p_response_code. Different codebases and different libraries genuinely disagree, which is why any decent converter makes it an explicit choice rather than a hidden assumption.

Digits are the other edge. address2Line could reasonably become address_2_line or address2_line, and the difference matters when the number carries meaning.

Why people get stuck here

• Doing it by hand. Forty identifiers is exactly the size where manual editing feels faster than automation and isn’t.
• Regex that half works. A pattern that handles camelCase usually mangles consecutive capitals, and the bug hides in the two identifiers that contain an acronym.
• Inconsistent conventions within one project. SQL columns in snake_case, JSON in camelCase, URLs in kebab-case — all correct, all needing conversion at the boundaries.
• Losing the mapping. Converting a list without keeping the original alongside makes verification impossible.

What good conversion looks like

It handles a whole list at once

The realistic unit of work is a column list, an interface, or a CSV header row — not a single name. Paste the block, convert the block, paste it back.

Acronym handling is a visible setting

Whether HTTPResponse becomes httpResponse or hTTPResponse should be a choice you make, not a surprise you discover in code review.

The target convention matches the destination

There’s a rough consensus worth following: snake_case for SQL columns and Python, camelCase for JavaScript and Java variables, PascalCase for types and classes, kebab-case for URLs, filenames and CSS.

Common mistakes to avoid

• Converting a database column list without checking whether any names are reserved words in the target system.
• Applying a conversion to values as well as keys, which silently corrupts data.
• Mixing conventions inside one layer — half the API in camelCase and half in snake_case is worse than either choice consistently.
• Assuming a round trip is lossless. HTTPResponse → http_response → HttpResponse doesn’t get you back where you started.
• Converting identifiers that are actually external contracts, like third-party API field names, which have to match exactly.

How to do it with Identifier Case Converter

The Identifier Case Converter takes a whole list and converts it in one pass, in your browser.

1. Paste the identifiers, one per line — a column list, an interface, a header row.
2. Choose the target convention for the language or database you’re moving to.
3. Set acronym handling explicitly: treat runs of capitals as one word, or split them fully.
4. Copy the converted block back, and keep the original alongside for verification.

For related transformations — text case, CSV headers, JSON keys — see the tools directory.

Frequently asked questions

Why do acronyms break case conversion?

Because a run of capital letters has no marked word boundary. Google’s style guidance for several languages recommends treating acronyms as ordinary words in identifiers — writing HttpResponse rather than HTTPResponse — precisely because it removes the ambiguity at the source.

Which convention should I use where?

Follow the destination language’s convention rather than a personal preference. Code that looks like the language it’s written in is easier for everyone else to read, and most linters enforce it anyway.

Are digits treated as word boundaries?

Sensible converters keep a digit run attached to the preceding word, so address2Line becomes address_2_line rather than something that loses the separation. If the number is meaningful, check the output rather than trusting the default.

Final thought

Convert at the boundary, not throughout. Pick the right convention for each layer, transform once where they meet, and don’t let a mapping function turn into scattered ad-hoc renaming.

Try the free Identifier Case Converter