camelCase to snake_case converter

Why camelCase and snake_case exist

camelCase and snake_case are two of the oldest conventions in programming, and the split between them is mostly historical. camelCase joins words by capitalizing each one after the first, so the humps in the middle of a name look like a camel's back: userProfileImage. snake_case keeps every letter lowercase and uses an underscore to mark each word boundary instead: user_profile_image. Both encode the same word boundaries; they just draw them differently.

The reason you still convert between them is that different ecosystems standardized on different defaults. JavaScript, TypeScript, Java, C#, Swift, and Kotlin lean heavily on camelCase for variables, object properties, and function names. Python, Ruby, Rust, SQL, and most database and config formats lean on snake_case. The moment data crosses a boundary between those worlds, a JSON payload feeding a Python service, a SQL result hydrating a TypeScript model, a CSV exported into a pandas frame, the naming has to be translated or the two sides stop agreeing on field names.

How the conversion actually works

Converting camelCase to snake_case is a two-step transformation. First, find every place where a lowercase letter or digit is immediately followed by an uppercase letter; that boundary is where a new word starts. Insert an underscore there. Second, lowercase the entire string. So userProfileImage becomes user_profile_image, and getHTTPResponse becomes get_h_t_t_p_response unless you add a rule for consecutive capitals.

That acronym edge case is the one that trips people up most. A naive converter turns parseJSONData into parse_j_s_o_n_data, which nobody wants. A better rule treats a run of capital letters as a single unit unless the last capital begins a new lowercase word, producing parse_json_data. The converter on this page handles common runs sensibly, but it is always worth scanning identifiers with acronyms (URL, ID, API, HTML) after a bulk conversion, because house styles disagree on whether the result should read api_key or a_p_i_key.

Numbers are the other gray area. Should address2Line become address2_line, address_2_line, or address2line? There is no universal answer, so pick one convention and apply it consistently across the codebase rather than letting each conversion decide on its own.

Where you reach for this conversion

The most common trigger is an API boundary. A JavaScript frontend sends camelCase keys, a Python or Rails backend expects snake_case, and somewhere a serializer has to map between them. Doing that mapping by hand for a wide object is exactly the kind of tedious, error-prone task that produces silent bugs when one field is mistyped, so batching the names through a converter first removes the guesswork.

Database work is the second big one. SQL column names are conventionally snake_case, so when you generate a schema from a TypeScript interface, or scaffold an ORM model from existing columns, every property name has to flip. Analytics pipelines hit the same wall: event properties defined in app code as camelCase often need to land in a warehouse as snake_case to match dbt and SQL conventions.

Paste a block of identifiers into the converter above to translate a whole list at once, then read the output back against your house style for acronyms and numbers before committing. It is faster than retyping and far less likely to introduce a typo than editing each name individually.