Convert snake_case to camelCase

snake_case to camelCase Converter

At the backend-to-frontend boundary, Python code and PostgreSQL schemas commonly use snake_case¹², while JavaScript and TypeScript frontends commonly use camelCase for function, object, and property names³. When you move identifiers between those ecosystems, every field name needs a consistent casing rule.

Where snake_case and camelCase diverge

Python code commonly uses snake_case for function and variable names¹, and PostgreSQL lets identifiers use underscores while conventionally writing names in lower case². MDN recommends camel case starting with a lowercase character for JavaScript function names, object properties, method names, and object instances³. Consequently, every API boundary between a Python or SQL backend and a JavaScript frontend needs a casing decision for every field. The same divergence appears when Ruby on Rails APIs serve data to React frontends, or when Rust libraries expose snake_case FFI bindings that JavaScript code consumes through WebAssembly modules. Each of these boundaries needs the same conversion, applied consistently, or field names silently fail to match at runtime.

Edge cases: leading underscores and consecutive separators

Leading underscores ("_private_field") strip the underscore and capitalize from the first word: "_private_field" becomes "privateField". Double underscores ("__init__") strip all leading and trailing underscores and join the remaining segments: "__init__" becomes "init". Yet Python treats single leading underscores as a non-public API convention, and double-underscore class names are subject to name mangling⁴, so avoid running Python dunder methods through this converter. Consecutive separators like "first__name" collapse to a single boundary: "firstName". SCREAMING_SNAKE_CASE inputs like "MAX_FILE_SIZE" convert to "maxFileSize", which is the standard JavaScript constant style when the value is imported as a module-level binding rather than an environment variable. Numbers embedded in identifiers maintain their position: "address_2" becomes "address2", which is valid in JavaScript but may require bracket notation for property access in some edge cases.

Workflow: mapping a PostgreSQL schema to TypeScript interfaces

Building on this, the pattern is: export your column names from the database, paste them here, and copy the camelCase output into a TypeScript interface block. You now have the camelCase equivalent of every column ready for your data access layer. CapyToolkit processes each line independently, making bulk conversion of a full table schema straightforward. The same workflow applies when writing a React component that reads from a Python API response. For Zod schema generation, paste the column names, convert to camelCase, and use the output as the field names in your validation schema. The resulting Zod object mirrors the API response shape and gives you runtime type safety that matches the backend contract without manual field-by-field mapping.

Automatic conversion at the API boundary with camelcase-keys and Axios transformers

Manually mapping snake_case API response fields to camelCase in every fetch handler creates redundant code that grows with each new endpoint. A conversion at the HTTP layer processes all responses automatically and keeps component code clean. Installing a single transformer at the Axios instance level means every component that consumes the shared client receives camelCase data without any per-request mapping logic.

The camelcase-keys npm package recursively converts all object keys from snake_case to camelCase.⁵ Install it with npm install camelcase-keys and call camelcaseKeys(data, { deep: true }) on the parsed JSON. Axios lets you apply this transformation globally through a transformResponse interceptor, so every API response arrives in your component as camelCase without any per-request mapping code.⁶

Axios response transformer configuration

Add a custom transformResponse to your Axios instance: axios.create({ transformResponse: [(data) => camelcaseKeys(JSON.parse(data), { deep: true })] }). Every response object, including nested arrays and embedded objects, converts to camelCase before reaching your code. Verify the transformation by logging a raw response and the transformed result side by side in a development test. If a field is already camelCase in the API response, camelcase-keys leaves it unchanged. Setting deep: true is important when your API returns nested objects; without it, only the top-level keys convert and nested snake_case fields pass through unconverted. Test both a flat response and a deeply nested one when verifying the interceptor.

The payoff is consistency across the whole client. Once the transformer runs at the Axios layer, no component needs to know the backend uses snake_case, so the casing mismatch stays invisible to application code. You can confirm the behavior in CapyToolkit by converting a sample response here and comparing it with the transformed output, which should match field for field before the data reaches your components.

Type-safe snake_case-to-camelCase mapping in TypeScript with utility types

TypeScript's template literal types, introduced in version 4.1, allow you to encode the snake_case-to-camelCase conversion at the type level.⁷ This produces a mapped type where every snake_case property key becomes its camelCase equivalent, giving the compiler the ability to check names at the boundary. Once you define the utility type, every new API response shape gets compile-time casing verification without writing a single runtime test, which catches mismatches before they reach the browser.

Runtime conversion and TypeScript type metadata

A SnakeToCamel<T> utility type uses TypeScript's infer keyword to split on underscores and capitalize the following letter. You can define it yourself or import it from type utility libraries like type-fest. Once defined, type UserDTO = SnakeToCamel<UserAPIResponse> produces a new type with all snake_case keys converted to camelCase at the type level, with no runtime behavior change needed. This approach catches mismatches at compile time rather than discovering them in production.

Pairing the type with camelcase-keys at the boundary

The type transformation and the runtime conversion must agree. Write a typed wrapper function: function toDTO<T>(raw: T): SnakeToCamel<T> { return camelcaseKeys(raw as any, { deep: true }) as SnakeToCamel<T> }. This function applies both the runtime key conversion and the TypeScript type conversion simultaneously. Your callers receive an object typed as camelCase with matching runtime keys, and TypeScript prevents any code that tries to access the original snake_case names.

When to use this

Use this when writing the mapping layer between a Python/SQL backend and a JavaScript/TypeScript frontend, or when converting a database schema to a TypeScript interface.

Examples

user_id
first_name
created_at
is_active
phone_number

userId
firstName
createdAt
isActive
phoneNumber

total_amount
shipping_address
payment_method

totalAmount
shippingAddress
paymentMethod