Convert Anything to camelCase

camelCase Converter,Convert Anything to camelCase

Readable JavaScript names often start small and grow with each word. camelCase keeps multi-word variables, function names, and object property keys readable without separators.¹

Yet the conversion is rarely one-to-one. Acronyms like "user_id" become "userId", but "http_code" should become "httpCode", not "hTTPCode". This tool handles those boundaries correctly and converts any input format to camelCase.

Where camelCase is required

JavaScript and TypeScript enforce camelCase for variables, function parameters, and object property names by community convention; the Airbnb and Google style guides both specify this.¹ Java uses camelCase for method names and local variables.² Swift and Kotlin follow the same pattern for all non-type identifiers.³ Furthermore, JSON property names from REST APIs almost universally use camelCase, making it the most common format in web development output. Go is an exception: it uses PascalCase for exported identifiers and camelCase for unexported ones, with no underscore-based convention at all.⁴ When your JavaScript frontend consumes data from a Go API, the PascalCase JSON keys still need camelCase conversion on the frontend side to match JavaScript conventions.

Edge cases: leading digits, separators, and empty strings

Identifiers cannot start with a digit in JavaScript, TypeScript, Java, or most typed languages.⁵ If your input starts with a number ("2waySync"), the converter produces "2waySync" unchanged since no valid camelCase form exists for a digit-prefixed identifier. Conversely, any separators (underscores, hyphens, dots, slashes) are treated as word boundaries. "background-color" becomes "backgroundColor" and "db.connection.pool" becomes "dbConnectionPool". Empty strings pass through unchanged, so pasting a list with blank lines between groups does not produce errors. SCREAMING_SNAKE_CASE inputs like "MAX_FILE_SIZE" convert to "maxFileSize", which is the conventional JavaScript form for values that originated as environment variables but are accessed as camelCase properties in configuration objects.

Workflow: mapping a database response to a TypeScript interface

Building on this, a common workflow is to paste PostgreSQL column names (which follow snake_case) into this tool and copy the camelCase output directly into a TypeScript interface. You get properly named properties in one pass, without renaming each field manually. The same pattern works when writing a fetch handler that maps a Python API response to a React component's prop types. CapyToolkit processes each line independently, so pasting 40 column names at once returns 40 camelCase property names. For projects using Zod for runtime validation, the camelCase output doubles as the field names in your schema definition, giving you a single source of truth for both the TypeScript type and the runtime validator. When the backend schema changes, you reconvert the updated column names and diff the output against your existing interface to see exactly which fields were added, removed, or renamed.

Mapping API response field names to camelCase object properties

REST APIs return JSON with field naming that reflects the backend language's convention. Python and Ruby backends typically return snake_case: user_id, first_name, created_at. Your JavaScript frontend expects camelCase for object properties. The conversion happens somewhere in your code, or you do it manually when writing types. Without a deliberate conversion strategy, frontend code silently reads undefined values from snake_case fields, and the resulting bugs only appear at runtime when a specific code path accesses the missing property. Understanding where that conversion belongs in your codebase keeps your component code clean and your type definitions aligned with what the API actually delivers.

Automating the TypeScript interface from a response schema

Paste the snake_case field names from your API documentation or a response sample, run them through this converter, and build the interface without retyping fields by copying the camelCase output straight into your type definition. You get the property names you will use in your frontend without typing each one manually or risking a misspelling. CapyToolkit processes each line independently, so a 30-field API response schema converts in one paste.

Keeping the generated interface in sync with the live API prevents drift. When a backend adds a field, you reconvert the updated schema and the new property name appears in your types immediately. You can compare the shapes in CapyToolkit by pasting the response fields and converting them, then checking that every property in your interface matches the converted output before you ship the change.

OpenAPI spec field names and frontend property naming

OpenAPI specs written for Python or Go backends often use snake_case property names in the components/schemas section. If you generate TypeScript client code from an OpenAPI spec, the generated types may use snake_case unless you configure a naming transformer. Running the spec field names through this converter before writing a manual transformer gives you a preview of what the camelCase output should look like, and you can compare it against the generator output to catch any discrepancy.

When third-party API field names do not follow camelCase

Payment gateways, shipping APIs, and government data sources often return field names in formats you did not choose: snake_case, SCREAMING_SNAKE, or even mixed formats within a single response. Normalizing those to camelCase in one place keeps the rest of your codebase consistent. Building a single normalization layer at the API client boundary means every downstream component reads predictable camelCase properties regardless of what the external service sends, which eliminates an entire class of integration bugs that are notoriously hard to reproduce in development environments.

Writing a mapping function before committing field names

Before writing a mapResponse() function, run the raw API field names through this converter and compare the camelCase output against what your component code actually uses. Mismatches between what the API returns and what your component expects are a common source of undefined bugs that appear only at runtime. Catching them at the naming stage, before the code is written, costs nothing.

GraphQL aliases as a camelCase normalization layer

GraphQL lets you alias field names in your query: userId: user_id. This is a clean way to consume a snake_case schema and expose camelCase fields to your frontend without writing a JavaScript mapping function. Paste the schema field names into this converter, copy the camelCase output, and use those as alias names in your GraphQL query. Your frontend sees camelCase properties regardless of how the underlying data layer names them.

When to use this

Use this when writing the TypeScript interface for a REST API response, mapping PostgreSQL column names to JavaScript object properties, or converting Python variable names for use in a JavaScript module.

Examples

user_id
first_name
created_at
is_active

userId
firstName
createdAt
isActive

background-color
font-size
border-radius
margin-top

backgroundColor
fontSize
borderRadius
marginTop