Convert Identifiers Between Programming Naming Conventions

Convert Identifiers Between Programming Naming Conventions

Every language and file format settles on its own naming convention, so code that moves data between them renames identifiers at every boundary. A PostgreSQL column called created_at becomes createdAt in a TypeScript interface, CreatedAt in a C# class and created-at in a CSS custom property or a URL slug. Renaming by hand is where acronym mistakes and stray separators slip in.

The case converter splits whatever you paste into a word list first, breaking at underscores, hyphens, dots, slashes and spaces as well as at lowercase-to-uppercase, letter-to-digit and acronym boundaries. It then rebuilds that word list in every convention at once, so a single paste answers every direction. Each line is converted on its own, which means a column of 40 field names pasted from a schema comes back as 40 converted names in the same order.

This page is grouped by target convention: camelCase, PascalCase, snake_case and kebab-case, then CONSTANT_CASE, dot.case and path/case. Each target starts with where that convention is required, followed by the pages for converting into it from the conventions you most often start from.

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 treats the digit as its own word and produces "2WaySync", which is still not a valid identifier, so rename it to start with a letter. 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

Convert kebab-case to camelCase

When CSS, HTML, or URL data enters JavaScript, kebab-case segments need camelCase object keys. When you read a CSS custom property into a JavaScript object, or when you map an HTML data attribute to a component prop, you need this conversion. "background-color" becomes "backgroundColor" and "data-user-id" becomes "dataUserId".

Furthermore, URL slugs are kebab-case, but the corresponding JavaScript variable or object key is camelCase. This tool handles the conversion for any kebab-case input.

Where kebab-case needs camelCase equivalents

The DOM style API uses camelCase: element.style.backgroundColor, not element.style.background-color.¹ React's inline style prop requires camelCase property names for the same reason.² HTML data attributes read via the dataset API are automatically camelCased by the browser without any extra mapping code: data-user-id becomes dataset.userId and data-product-name becomes dataset.productName for every kebab-case attribute you add to the document object model.³

DOM style and dataset mappings

The DOM style API requires camelCase property names even though the CSS source uses kebab-case. "background-color" becomes "element.style.backgroundColor", and "font-size" becomes "element.style.fontSize". Similarly, the browser's dataset API automatically converts kebab-case HTML attribute names to camelCase JavaScript property names: "data-user-id" becomes "dataset.userId". Building on this, any configuration object that mirrors CSS properties, such as the style objects used in CSS-in-JS libraries, uses camelCase for the JavaScript side.

CSS-in-JS libraries inherit the same camelCase requirement on the JavaScript side. A styled-components or Emotion style object keys its properties in camelCase so that the value you assign maps directly onto the corresponding DOM style property. When the same design token is referenced in a CSS file as kebab-case and in a style object as camelCase, generating both names from one source avoids the bug where the CSS declaration and the JavaScript key disagree on casing. The browser applies the style only when both sides resolve to the identical property, so a single conversion step keeps them consistent.

Edge cases: multiple hyphens and numeric segments

Multiple consecutive hyphens are collapsed to a single word boundary, so two hyphens followed by a word produces a single camelCase transition. Numbers after a hyphen are treated as the start of a new word: "h1-tag" becomes "h1Tag". Yet numbers at the start of an identifier produce output like "1StResult" from "1st-result", which is not a valid JavaScript identifier. Review output when the source contains numeric prefixes. CSS custom property names that begin with the standard two-hyphen prefix, such as "font-size-body" with its prefix attached, convert cleanly, because the leading hyphens are dropped and produce no empty first segment. PascalCase segments within kebab-case input, like "fontSize-body", also split at their camelCase boundary, so they come out as "fontSizeBody" rather than a merged word.

Workflow: reading CSS custom properties in JavaScript

Building on this, when you have a list of CSS custom property names and want the JavaScript object keys for a CSS-in-JS mapping, paste the CSS names without the two-hyphen prefix, convert to camelCase, and use the output as your object keys. For example, "color-primary" becomes "colorPrimary" and "font-size-body" becomes "fontSizeBody". CapyToolkit converts each line independently, making bulk conversion straightforward. For CSS-in-JS libraries like styled-components or Emotion, the camelCase keys in your style objects match the JavaScript convention while the kebab-case equivalents match the CSS source. When you need to toggle between reading a CSS custom property value and setting a JavaScript style property, having both naming formats from the same source string prevents the common bug where a camelCase key is used in a getPropertyValue call and silently returns an empty string.

Reading CSS custom properties in JavaScript with getPropertyValue and dataset

Reading CSS custom property values in JavaScript requires using the exact kebab-case name with getComputedStyle(el).getPropertyValue(customPropertyName). When you store the token name as a camelCase JavaScript variable and need the kebab-case CSS name to read it, this converter produces the exact CSS name from the identifier you already have. Any mismatch in casing between the declaration and the read call results in an empty string returned silently, with no exception thrown to alert you to the bug.

A design system that exports token names as camelCase constants uses the kebab-case form when reading the value from the DOM. The JavaScript call uses the property name after the two-hyphen prefix with getPropertyValue. Paste your camelCase token constant names into this converter to generate the exact CSS custom property names for the getPropertyValue call. Mismatches between the camelCase constant and the kebab-case CSS name produce empty strings silently.

CSS custom properties require the exact kebab-case name

Unlike standard CSS property names, custom property names are case-sensitive once the two-hyphen prefix is in place.⁴ A property named "Color-Primary" with the prefix differs from "color-primary" with the prefix, and the browser treats them as two separate values. When you read a custom property in JavaScript, the string passed to getPropertyValue must match the declaration exactly, including the case of every character after the prefix. Paste your declared property names in and you get the exact CSS name getPropertyValue expects before you write the JavaScript that reads it. The output from this tool matches the format required by getPropertyValue and setProperty.

Angular property binding: from kebab-case HTML attributes to TypeScript inputs

Angular uses kebab-case for HTML attribute names in templates and camelCase for TypeScript class properties and @Input() decorators.⁵ This two-format system is built into the Angular architecture: HTML attribute syntax uses kebab-case because the HTML specification requires it for attribute names, while TypeScript class members follow camelCase. Maintaining this convention consistently across every component in your codebase keeps template bindings predictable and prevents the subtle runtime errors that appear when a kebab-case attribute does not match its corresponding input decorator name.

An Angular component with @Input() userId: string receives the value through the template attribute [user-id]="userId" in a parent template. Angular's template compiler handles the mapping from the kebab-case attribute to the camelCase input property. When you read the Angular documentation for a third-party component library, the listed @Input() names are camelCase, but the attribute you write in your template is the kebab-case equivalent. Use this converter to produce the template attribute name from the TypeScript input name.

Component selector naming and the kebab-case selector convention

Angular component selectors use kebab-case: selector: 'app-user-card'. The component class name is PascalCase: class UserCardComponent. Converting between these two formats when building new components follows the same rule: the selector is the kebab-case version of the component name. Paste your PascalCase component names into this converter to generate the corresponding selectors before writing the component decorator. CapyToolkit processes each line independently, so generating selectors for a list of new component names takes one paste.

When to use this

Use this when mapping CSS property names to JavaScript style object keys, converting HTML data attribute names to JavaScript property names, or building a camelCase API client from kebab-case URL segments.

Examples

color-primary
spacing-md
font-size-body
border-radius

colorPrimary
spacingMd
fontSizeBody
borderRadius

data-user-id
data-product-name
data-category-id

dataUserId
dataProductName
dataCategoryId

Convert snake_case to camelCase

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

Convert Anything to PascalCase

Before you name a class, interface, component, or C# type, PascalCase gives the identifier an uppercase-first shape.

PascalCase and camelCase look similar but follow different rules: "UserProfile" is PascalCase, "userProfile" is camelCase. This tool converts any input, snake_case, kebab-case, spaces, or mixed formats, to PascalCase in one pass. That small shape helps readers recognize named types before they inspect fields in a codebase.

Where PascalCase is used

C# uses PascalCase for all public-facing identifiers: classes, methods, properties, events, and namespaces follow the Microsoft C# Coding Conventions.¹ TypeScript and JavaScript use it for class names and React component names. In Swift, struct and class names are PascalCase.² Building on this, GraphQL type names³ and Protobuf message names⁴ also use PascalCase, making it the convention for any named type across languages, not just object-oriented ones. Kotlin uses PascalCase for class and enum type names,⁵ matching the JVM convention established by Java. Even in languages where PascalCase is not the default, like Python (which prefers snake_case for most identifiers), class names are PascalCase per PEP 8.⁶ This near-universal agreement on PascalCase for named types means that a developer reading unfamiliar code in any modern language can immediately recognize type identifiers by their uppercase-first shape.

Edge cases: acronyms, numbers, and mixed separators

Acronyms inside PascalCase are treated as individual words with only the first letter capitalised: "html_parser" becomes "HtmlParser" rather than "HTMLParser". Numbers act as word boundaries: "form2submit" becomes "Form2Submit". Yet inputs that already contain correct PascalCase (like "UserProfile") are preserved correctly because the splitter detects the camelCase boundaries and rebuilds the same form. Mixed separator input such as "my-mixed_separator" produces "MyMixedSeparator", which handles the common case where configuration keys use a combination of hyphens and underscores across different sections. Single-word inputs like "user" become "User", making this converter useful for generating class names from simple nouns. Leading digits in inputs like "2ndAttempt" split into their own word and produce "2NdAttempt", which is not valid PascalCase, so rename digit-prefixed identifiers by hand.

Workflow: generating class names from a database schema

A practical use: paste your PostgreSQL table names (which are snake_case) into this tool and convert to PascalCase to get the model class names. "user_profile" becomes "UserProfile", "order_line_item" becomes "OrderLineItem". Consequently, your ORM models and database tables share the same vocabulary, just in different cases. This naming alignment matters when you use ORM autogeneration tools that derive class names from table names: the generated code reads naturally because the class name is the PascalCase version of the table name a developer would already recognize from writing SQL queries.

ORM class names from table names

SQLAlchemy, Django ORM, and Entity Framework all derive class names from database table names automatically. When your table is "user_profile", the corresponding Python or C# class becomes "UserProfile". Paste your full list of PostgreSQL or MySQL table names in to generate model names from your schema and copy the PascalCase output directly into your ORM model definitions. CapyToolkit processes each line independently, so converting an entire schema's worth of table names takes one paste. For projects using Prisma, the model name in schema.prisma is PascalCase by convention, and the @map attribute links it to the snake_case table name in the database. Converting your existing table names to PascalCase before writing the Prisma schema ensures the model names follow the expected convention from the start.

The payoff is fewer surprises in generated code. When the model name matches the PascalCase version of the table, developers reading the ORM layer recognize the source immediately without cross-referencing SQL. You can confirm the mapping in CapyToolkit by pasting your table names and converting them, then checking that each output matches the class name your ORM expects before you write the models.

PascalCase in GraphQL schema definitions and type generation

GraphQL schemas use PascalCase for all type names: type UserProfile, type OrderLineItem, type PaymentMethod. When you generate TypeScript types from a GraphQL schema using GraphQL Code Generator, the generated output uses PascalCase type names matching the schema. Starting with correctly named schema types prevents a cascade of renaming in generated code. A single type rename in the schema forces you to regenerate every client stub, update every import statement across the codebase, and redeploy every service that depends on the generated types, which is why getting the PascalCase name right before writing the schema saves hours of coordinated refactoring later.

GraphQL Code Generator reads your .graphql schema files and produces TypeScript interface and type definitions with the same PascalCase names. If your schema type is user_profile (non-standard), the generated TypeScript is user_profile too, which violates TypeScript conventions. Paste your planned type names into this converter, verify the PascalCase output, and use those names in your .graphql schema files before running the code generator.

Apollo Client and generated types from PascalCase schemas

Apollo Client's cache identifies types by their __typename field, which comes from your GraphQL schema type name. A schema type UserProfile produces __typename: "UserProfile" in query responses. Switching the type name after the frontend has cached data under the old name requires a cache invalidation or migration step. Getting the PascalCase name right before writing the schema prevents this problem. CapyToolkit converts each line independently, so naming a full schema's worth of types takes one paste.

Protobuf message naming conventions and the .proto to TypeScript pipeline

Protobuf message names use PascalCase by the Protocol Buffers style guide.⁴ Service names and RPC method names also use PascalCase. When you design a gRPC API alongside a REST API or a Python backend, consistent PascalCase naming in the .proto file keeps generated TypeScript and Python stubs aligned with their respective language conventions. Getting the naming right before the first schema commit is far cheaper than renaming messages after client libraries have been published and imported by downstream teams that depend on the generated code.

The buf build tool enforces Protobuf naming rules through lint checks. buf lint with the BASIC lint category includes the MESSAGE_PASCAL_CASE and SERVICE_PASCAL_CASE rules.⁷ Both rules reject any message or service name that is not PascalCase. Running buf lint in CI prevents non-PascalCase names from reaching the schema before generated stubs are written.

buf lint and naming convention enforcement

Add a buf.yaml file with lint: { use: [BASIC] } to enable the naming rules without configuring individual rules by hand. The BASIC category includes MESSAGE_PASCAL_CASE, RPC_PASCAL_CASE, and FIELD_NAMES_LOWER_SNAKE_CASE, covering the full set of Protobuf naming conventions in one line of configuration. Run buf lint locally before committing schema changes to verify all message and service names are PascalCase before pushing to the team's schema registry.

When to use this

Use this when creating TypeScript interfaces, React component names, C# class names, or GraphQL type names from database table names or API resource labels.

Examples

user_profile
order_line_item
payment_method
shipping_address

UserProfile
OrderLineItem
PaymentMethod
ShippingAddress

user-card
product-list
checkout-form
navigation-bar

UserCard
ProductList
CheckoutForm
NavigationBar

Convert camelCase to PascalCase

Before a camelCase value becomes a named type, its first letter needs to change. "userProfile" (camelCase) and "UserProfile" (PascalCase) represent the same concept, but one names a variable and the other names a class or interface. Converting from one to the other is just capitalizing the first character, and doing it consistently across dozens of identifiers benefits from automation.

Yet the conversion is one-directional in meaning: camelCase variables become PascalCase types, not the reverse. React component names, TypeScript interfaces, and C# classes all require PascalCase.

When variable names become type names

TypeScript's convention: variables and function parameters are camelCase; interfaces, types, and classes are PascalCase.¹ When you extract a shape from a function's parameter and elevate it to a named interface, the name changes from camelCase to PascalCase. React component function names must be PascalCase because JSX uses the first character to distinguish between HTML elements (lowercase) and components (uppercase).² Building on this, when you refactor an anonymous object into a named class, its name moves from camelCase to PascalCase. C# and Java enforce the same distinction: local variables are camelCase, while any named type (class, interface, enum, record) is PascalCase.³ This consistency across languages means that a developer working in a polyglot codebase can identify type names by their uppercase-first shape regardless of which language a particular file is written in.

Edge cases: single words, acronyms, and leading digits

Single-word camelCase names like "user" become "User". For names starting with an acronym ("htmlParser"), only the first letter changes: "htmlParser" becomes "HtmlParser". Consequently, the acronym loses its all-caps form because only the first character is uppercased.⁴ There is no single correct spelling for acronyms in compound identifiers: some codebases keep every letter capitalized (encodeURIComponent) while others capitalize only the first letter (XmlHttpRequest), and the built-in XMLHttpRequest global mixes both styles.⁴ For names starting with a digit ("2waySync"), the first character does not change (digits cannot be uppercased), resulting in a non-standard PascalCase form. Multi-word camelCase names with embedded acronyms, like "userId", produce "UserId" rather than "UserID", which follows the Microsoft and TypeScript convention of treating acronyms as regular words in PascalCase. Empty strings pass through unchanged, and whitespace-only input produces an empty result. When your camelCase input is already PascalCase (like "UserProfile"), the output is identical because only the first character matters and it is already uppercase.

Workflow: elevating camelCase props to TypeScript interface names

Building on this, a practical use: when you have a list of React component prop holder names in camelCase and want to generate the corresponding TypeScript interface names, paste the names, convert to PascalCase, and append "Props" to each. "userCard" → "UserCard" → "UserCardProps". CapyToolkit converts each line independently, so a full component inventory processes in one pass. For design system documentation, converting your component names to PascalCase and appending "Props" gives you the interface names that appear in your generated API docs. When a new developer joins the team and needs to find the prop types for a component, the predictable naming pattern (component name + "Props") means they can locate the interface without searching through files. For Vue.js projects using TypeScript, the same pattern applies: component props defined with defineProps<UserCardProps>() use the PascalCase interface name derived from the camelCase component name.

JSX component naming and the PascalCase rendering rule

React's JSX parser uses the case of the first character to distinguish HTML elements from custom components.² Lowercase-starting identifiers like <button> are DOM elements; uppercase-starting identifiers like <Button> are React components. PascalCase is mandatory, not optional, for all React component names. This distinction is baked into the JSX specification itself, which means that every React project enforces PascalCase for components regardless of whether the team uses TypeScript, Flow, or plain JavaScript. A camelCase component name in JSX will never render as a component, making the camelCase-to-PascalCase conversion a prerequisite for every new component you add to the project.

Why lowercase React components are silently ignored

If you write const myButton = () => <button>Click me</button> and then use <myButton /> in JSX, React renders nothing and throws no error at compile time. The JSX transpiler interprets myButton as an unknown HTML element, not a component. The component never renders. Naming mistakes at this boundary are among the hardest JSX bugs to spot because the output is simply empty. If you shift a camelCase name to PascalCase before wiring up the import, you prevent this class of error entirely.

Higher-Order Component naming conventions

Higher-Order Components in React take a component and return a new component. The pattern const withAuth = (WrappedComponent) => ... uses camelCase for the HOC function (withAuth) and PascalCase for the component parameter (WrappedComponent). When you rename a camelCase HOC result to PascalCase for use in JSX, this converter produces the correct output. The HOC naming convention separates the HOC function name (camelCase) from the component it returns (PascalCase), and this tool handles that boundary.

The same PascalCase requirement extends to the component you return, not just the one you wrap. A HOC that returns a component must give that returned value a PascalCase name so JSX recognizes it as a component rather than an HTML tag. When the wrapped value keeps its PascalCase parameter name and the returned component also uses PascalCase, the import chain reads consistently from the call site down to the rendered element. Naming the HOC result with this converter before wiring the export prevents the empty-render bug that comes from a lowercase-starting identifier slipping into the JSX tree.

Extracting TypeScript interface names from camelCase variable shapes

TypeScript interfaces represent the shape of an object. When you extract an inline object shape from a function parameter and turn it into a named interface, the name conventionally changes from camelCase to PascalCase. Batch-converting candidate variable names to PascalCase before choosing the interface name speeds up this naming decision.

Refactoring inline objects to named interfaces

In early TypeScript code, parameter types are often written inline: function createUser(data: { userId: string; firstName: string }). Extracting this to a named interface requires choosing a descriptive name that represents the shape rather than the specific parameter: interface UserData { userId: string; firstName: string }. The parameter variable name data does not directly suggest the interface name, but the function name createUser often does. Paste your camelCase function or variable names into this converter to generate a batch of candidate PascalCase interface names, then select the most descriptive one for each shape. The .NET design guidelines put the same rule in writing for class libraries: name classes and structs with nouns or noun phrases in PascalCasing, so that a type name reads differently from a method name.⁵

When to use this

Use this when naming TypeScript interfaces from camelCase variable shapes, creating React component names from camelCase prop holders, or converting JavaScript class instances to class definition names.

Examples

userProfile
orderItem
paymentMethod
shippingAddress

UserProfile
OrderItem
PaymentMethod
ShippingAddress

userCard
productList
checkoutForm
navigationBar

UserCard
ProductList
CheckoutForm
NavigationBar

Convert snake_case to PascalCase

Before TypeScript interfaces, C# classes, or React components can mirror a snake_case schema, each table name needs an uppercase-first type name. "user_profile" becomes "UserProfile", "order_line_item" becomes "OrderLineItem". Doing this manually for an entire schema is tedious and error-prone.

Consequently, this tool splits on underscores, capitalizes the first letter of each segment, and joins them without separators to produce PascalCase output.

When snake_case needs to become PascalCase

PostgreSQL and most relational databases use snake_case for table and column names. TypeScript code that consumes those schemas via an ORM or API layer uses PascalCase for interface and type names. Python backend services with snake_case model attributes expose PascalCase type names in their OpenAPI specifications. The conversion is a structural necessity at every boundary where a relational schema meets a statically typed language that follows PascalCase conventions for its type system.

From database names to typed interfaces

PostgreSQL and MySQL store table names in snake_case by convention,¹ but the TypeScript interfaces that represent those tables in your application code use PascalCase.² "user_profile" becomes "UserProfile", and "order_line_item" becomes "OrderLineItem". Building on this, gRPC proto file message names and GraphQL type names are also PascalCase³, and when you generate them from a snake_case schema, this conversion is the essential first step. C# and Java class names follow the same PascalCase convention, which means a single snake_case-to-PascalCase conversion serves every language in a polyglot backend. When you design a new microservice that shares a database with an existing Python service, converting the existing table names to PascalCase gives you the C# or TypeScript class names that match the domain vocabulary already established in the database schema.

The same table name can feed three different consumers without three separate hand conversions. A Python service reads it as snake_case, a TypeScript frontend imports it as a PascalCase interface, and a gRPC client receives it as a PascalCase message, all derived from the single snake_case source. Generating each consumer's names from one conversion keeps them aligned when the schema changes, because a rename in the database propagates through the same mapping rather than through three independently maintained name tables. That alignment is what prevents the runtime mismatch where one layer expects UserProfile and another still references user_profile.

Edge cases: leading underscores and double underscores

Leading underscores like "__init__" or "_private_field" strip the leading underscore(s) and capitalize from the first actual word. "__user_data__" produces "UserData" with no leading underscore preserved. Consecutive underscores between words are treated as a single separator. Yet if you need to preserve Python's dunder convention, do not run dunder names through this converter; use it only for regular snake_case identifiers. SCREAMING_SNAKE_CASE input like "MAX_FILE_SIZE" produces "MaxFileSize", which is the standard PascalCase form for constants that need to become type or class names. Numbers embedded in identifiers maintain their position: "address_2" becomes "Address2", which is valid PascalCase even though it ends with a digit. Empty lines pass through unchanged, so pasting a schema export with blank lines between table groups does not produce errors.

Workflow: generating TypeScript interfaces from a PostgreSQL schema

Building on this, here is the workflow: export your PostgreSQL table names in a list, paste them into this converter, and copy the PascalCase output as TypeScript interface names. Then convert the column names from snake_case to camelCase for the property names. CapyToolkit handles each line independently, so converting an entire schema's table names and column names takes two paste operations. For Prisma schema generation, the PascalCase output becomes the model name in schema.prisma, and Prisma automatically maps it to the snake_case table name via the @@map attribute.⁴ When you run prisma db pull on an existing database, Prisma performs this same conversion automatically, but previewing the output beforehand helps you catch any table names that produce unexpected PascalCase results, such as tables with consecutive underscores or non-ASCII characters.

Generating Protobuf message names and gRPC service names from snake_case schemas

Protocol Buffers require PascalCase for all message names, service names, and RPC method names per the official style guide.⁵ When you design a gRPC API alongside an existing PostgreSQL schema, converting table names and type names to PascalCase before writing the .proto file ensures the generated TypeScript and Python stubs use names that match existing code conventions.

The Protobuf compiler protoc generates language-specific code from .proto files. A message named user_profile (non-standard) generates a Python class named user_profile and a TypeScript interface named user_profile, both of which violate their respective language conventions. Paste your snake_case table names in, copy the output, and you have PascalCase message names for your .proto before you write a single line of the schema.

buf lint message naming rules

buf lint enforces the MESSAGE_PASCAL_CASE rule when you use the BASIC or DEFAULT lint category. Running buf lint on a schema where message names are snake_case produces errors listing each violation. Fixing the names before generating stubs from the schema prevents a cascade: once generated stubs exist and are imported by application code, renaming a message name requires regenerating all stubs and updating every import.

zod schema naming conventions for TypeScript from PostgreSQL tables

Zod is the dominant TypeScript-first validation library. Its schema objects use PascalCase naming by convention, following the TypeScript pattern where types and schema-like objects use PascalCase.⁶ When you generate Zod schemas from a PostgreSQL table definition, converting table names to PascalCase before writing the schema names keeps your validation code consistent with TypeScript conventions.

A Zod schema for a user_profile table is conventionally named UserProfileSchema. The internal field names within the schema use camelCase matching the TypeScript interface. Paste your snake_case table names into this converter, append Schema to each output, and you have the Zod schema names ready to use. Field names within the schema require a separate conversion to camelCase.

Prisma model naming and snake_case-to-PascalCase mapping

Prisma uses PascalCase for model names and maps them to snake_case database tables automatically. Running prisma db pull on an existing PostgreSQL schema generates a schema.prisma file with PascalCase model names derived from snake_case table names: a user_profile table becomes the UserProfile model. Understanding this conversion means you can predict the model names before running db pull, which helps when writing queries against the schema before the pull is complete.

When to use this

Use this when writing TypeScript interfaces from a PostgreSQL schema, generating C# class names from Python model attributes, or mapping a snake_case API response schema to PascalCase type names.

Examples

user_profile
order_line_item
payment_method
shipping_address

UserProfile
OrderLineItem
PaymentMethod
ShippingAddress

user_card
product_list
checkout_form

UserCard
ProductList
CheckoutForm

Convert Anything to snake_case

When backend data crosses into Python, SQL, YAML, or JSON, snake_case is the format that usually survives. Getting identifiers into that shape before committing saves a round of find-and-replace later.¹

This tool handles any input format (camelCase fields, PascalCase class names, Title Case headings, kebab-case slugs) and converts each to snake_case by splitting on all boundary types before joining with underscores. It is useful before linting, migrations, API mapping, or documentation updates.

Where snake_case is used

Python enforces snake_case for variables, functions, and module names per PEP 8, the language's official style guide.¹ Beyond Python, PostgreSQL column names follow snake_case by convention, making ORM mappings cleaner.² Environment variable naming in Linux shells and Docker Compose files uses SCREAMING_SNAKE, the uppercase cousin. Furthermore, Ruby, Rust, and Elixir all default to snake_case for function and variable names, making it the most cross-language-compatible identifier style for backend code.³ YAML and TOML configuration files across the DevOps ecosystem, from GitHub Actions workflow files to Helm chart values, use snake_case keys by convention. Even C and C++ projects that predate Python often adopt snake_case for internal APIs, and the Linux kernel coding style mandates it for all function and variable names across millions of lines of code.⁴

Edge cases: acronyms, numbers, and empty input

Acronyms in camelCase inputs (like "parseHTML" or "getHTTPCode") stay together as one word, splitting only where the acronym ends. "parseHTML" becomes "parse_html" and "getHTTPCode" becomes "get_http_code". Numbers follow the same logic: "address2" becomes "address_2" and "h1Tag" becomes "h_1_tag". Yet empty lines are passed through unchanged, so pasting a list with blank separators between groups does not produce unwanted underscores. Mixed input formats combine correctly: a string like "XML-HTTP-Request" produces "xml_http_request" regardless of whether the original separators were hyphens, spaces, or camelCase boundaries. PascalCase class names like "UserProfile" convert cleanly to "user_profile". When your input already contains underscores, the converter preserves them as word boundaries rather than doubling them up, so "first__name" correctly yields "first_name" with single underscore separation.

Workflow: renaming fields before writing a database migration

Building on this, here is a practical pattern. When you have a TypeScript interface with camelCase fields and need to write a PostgreSQL migration, paste the field names into this tool, copy the snake_case output, and use those names directly in your CREATE TABLE statement. You avoid manual renaming one field at a time, and your column names match the ORM expectations on the first try. The same process works when mapping a REST API response to a Python dataclass. For Alembic migrations in SQLAlchemy, the column names you write in op.add_column() calls must match the model attribute names exactly. Getting them right in one conversion pass before writing the migration prevents a follow-up renaming migration later, which is especially important once the migration has run in production and rollback requires coordinated downtime.

Preparing field names before writing database migration files

Database migration scripts are permanent. Once a migration runs in production, renaming a column requires another migration, a deploy, and coordination with any queries that reference the old name. Getting the name right the first time matters, and snake_case is the column-naming convention across PostgreSQL, MySQL, and SQLite. A single poorly named column in a production migration can trigger hours of coordinated downtime across multiple services, which is why batch-converting your field names before writing the migration is a small investment that prevents an expensive operational incident. The converter handles every input format you might paste into it, including camelCase, PascalCase, kebab-case, and mixed separators, so you can standardize from any source without manual cleanup.

ORM field mapping and column naming

SQLAlchemy, Django ORM, and Active Record all use snake_case Python or Ruby attribute names and map them directly to column names unless you override explicitly.⁵ Paste your planned attribute names in to verify the column names before migrating, then copy those names into both your migration file and your model definition at the same time. The two stay in sync because they come from the same conversion pass. CapyToolkit processes each line independently, so a schema with 40 fields converts in one paste.

Keeping the model and migration aligned prevents a common class of bugs. When the model attribute and the column name diverge, queries fail at runtime in ways that unit tests rarely catch. You can confirm the names match by running your field list through CapyToolkit and checking that the converted output is identical in both files, which removes the manual cross-check from the review process.

Converting identifiers for environment variables and shell scripts

Environment variables in UNIX-like operating systems are uppercase by convention, but the internal naming still uses underscores between words. Bash scripts, Docker Compose files, and .env templates all follow this pattern, and snake_case is the intermediate step in generating those names. Converting your source identifiers to snake_case first and then applying an uppercase step is a reliable two-step workflow that avoids the naming inconsistencies that arise from manual editing.

From camelCase config keys to SCREAMING_SNAKE environment variable names

Application configuration often starts as camelCase in source code: maxConnections, dbHost, apiTimeout. Converting to snake_case first gives you the lowercase form: max_connections, db_host, api_timeout. From there, applying UPPERCASE produces the final environment variable name. This two-step approach prevents the naming inconsistencies that arise when developers manually edit environment variable names from memory. Paste your camelCase config key list into this converter, copy the snake_case output, then run it through the UPPERCASE converter for the final result. CapyToolkit handles the first conversion; the UPPERCASE converter handles the second.

Shell variable naming in CI pipeline scripts

GitHub Actions, GitLab CI, and Bash scripts use uppercase snake_case for environment variables passed between steps. When your pipeline sets output variables from a Node.js script that uses camelCase property names, you need to convert before exporting. Running the camelCase property names through this converter first gives you the intermediate snake_case form, and from there the SCREAMING_SNAKE form follows directly.

When to use this

Use this when you need to convert TypeScript interface fields to database column names, rename Python variables to match PEP 8, or produce snake_case keys for a YAML config file.

Examples

userId
firstName
createdAt
isEmailVerified
phoneNumber

user_id
first_name
created_at
is_email_verified
phone_number

Article Title
Published Date
Author Name
Category Tag

article_title
published_date
author_name
category_tag

Convert camelCase to snake_case

JavaScript and TypeScript use camelCase for variable names¹; Python, SQL, and most configuration formats use snake_case². When you move data between these ecosystems (writing a Django model from a TypeScript interface or mapping a REST response to a database column), you need to rename every field.

Where camelCase and snake_case are used

JavaScript and TypeScript use camelCase for all variable and function names; Python, PostgreSQL, and most ORM frameworks use snake_case². REST APIs built with Python (FastAPI, Django REST Framework) return snake_case JSON fields by default³. Consequently, every JavaScript frontend that consumes a Python API has a casing mismatch to resolve. TypeScript interfaces must match the actual field names from the response, so those interface properties need to be snake_case when the backend sends them that way, or a mapping layer must convert them. Ruby and Rust also default to snake_case for function and variable names, which means the camelCase-to-snake_case conversion is relevant far beyond the JavaScript-Python boundary. Environment variables in Docker Compose and CI pipelines use SCREAMING_SNAKE_CASE, the uppercase variant, making this conversion the first step before applying uppercase transformation.

Edge cases: acronyms, numbers, and mixed inputs

Acronyms stay together as one word: "userID" becomes "user_id" and "parseHTML" becomes "parse_html", the same results that "userId" and "parseHtml" produce. Numbers act as word boundaries: "address2" becomes "address_2" and "h1Tag" becomes "h_1_tag". Mixed inputs with existing underscores or hyphens also split correctly: "phone-number" and "phone_number" both produce "phone_number". Consecutive uppercase letters that form an acronym without lowercase separation, like "IOStream", split where the next capitalized word begins: "io_stream". That covers source identifiers that follow the Microsoft C# convention of PascalCase with two-letter acronyms in uppercase, so you do not need to normalize them first. Empty lines in a multi-line paste pass through unchanged, so blank separators between groups of fields do not produce unwanted underscores.

Workflow: converting a TypeScript interface to a Python dataclass

Building on this, here is the exact workflow. Copy your TypeScript interface property names (just the names, one per line). Paste them in and convert a whole interface to snake_case in a single step, then copy the output and use those names as your Python dataclass attributes. The tool processes each line independently, so a 20-field interface converts in one pass. You then annotate the types in Python and the mapping is complete. For Pydantic v2 models, the snake_case attribute names map directly to JSON field names by default, which means your Python model and the TypeScript interface share the same vocabulary through the API contract. When the backend adds a new field, you convert the new name, append it to the dataclass, and the integration stays in sync without a manual find-and-replace across multiple files.

Enforcing naming conventions at the JavaScript-Python boundary with linters

Naming conventions at the JavaScript-Python boundary are the most common source of undetected casing violations in full-stack codebases. Each language enforces its own convention through tooling, but neither tool knows about the other side of the boundary. Adding linting rules on both sides closes that gap before a mismatch reaches code review. When a Python backend adds a new snake_case field and the TypeScript frontend does not update its interface, the mismatch passes silently through local development and only surfaces in production when a component reads an undefined property.

ESLint camelcase rule for JavaScript and TypeScript projects

ESLint's built-in camelcase rule flags any variable or property name that is not camelCase.⁴ When your TypeScript frontend receives a Python API response and assigns snake_case fields directly to variables, ESLint catches the violation. Configure the rule with "allow": [] to reject all exceptions, or add specific field names to the allow list for cases where you deliberately keep the raw API name.

Configuring this rule early saves time during code review. When the camelcase rule is active, a developer who pastes a raw snake_case field from a Python response sees the error immediately in the editor rather than shipping a silent mismatch. You can verify your setup in CapyToolkit by pasting a converted field list and comparing it against the original, which makes the casing boundary visible before the code ever reaches a linter. The @typescript-eslint/naming-convention rule provides finer control and can enforce camelCase on all variable, parameter, and property selectors simultaneously in one rule configuration.⁵

pep8-naming plugin for Python CI

The pep8-naming package extends flake8 with naming checks: N801 for PascalCase class names, N802 for lowercase function names, and N803 for lowercase argument names.⁶ Adding it to your [flake8] or [tool.flake8] configuration in setup.cfg or pyproject.toml ensures every snake_case violation produces a CI failure. Run pip install pep8-naming and flake8 with the N rule selected to see only naming violations without other style warnings from unrelated rules.

Pydantic alias_generator: accepting camelCase POST bodies in Python APIs

Pydantic v2 provides a clean mechanism for accepting camelCase JSON in a Python API while keeping snake_case model attributes internally. Understanding how to configure it prevents the common pattern of writing a manual field aliasing function for every model. The same alias configuration also simplifies testing because your test code can send camelCase request bodies that match what the real frontend sends, which means your integration tests exercise the exact same serialization path as production traffic.

Setting model_config = ConfigDict(alias_generator=to_camel, populate_by_name=True) in a Pydantic v2 model imports to_camel from pydantic.alias_generators and generates camelCase aliases for all snake_case fields automatically.⁷ Your FastAPI route then accepts {"userId": 123} as a POST body and maps it to user_id on the Python model without any manual alias declarations. The populate_by_name=True setting ensures you can still initialize the model with snake_case names in your own Python code.

Verifying the alias configuration in FastAPI docs

FastAPI generates an OpenAPI schema from your Pydantic models automatically. When you add alias_generator=to_camel, the schema at /docs shows camelCase property names in the request body editor. Run the dev server, open /docs, expand your POST route, click "Try it out", and confirm the example JSON uses camelCase. If it shows snake_case instead, the alias_generator is not applied yet. This visual check catches misconfiguration before integration tests do.

When to use this

Use this when migrating a TypeScript interface or JavaScript object to a Python data class, SQLAlchemy model, or any system that follows snake_case conventions.

Examples

userId
firstName
lastName
createdAt
isEmailVerified

user_id
first_name
last_name
created_at
is_email_verified

orderId
shippingAddress
totalAmount

order_id
shipping_address
total_amount

Convert kebab-case to snake_case

When kebab-case names enter Python code, their separators need to change before the names can become variables or database columns. When a route path like "user-profile" needs to map to a Python function named "user_profile", or when a CSS custom property "font-size-body" maps to a Python config key "font_size_body", this converter handles the separator swap.

Consequently, the conversion is straightforward (hyphens become underscores and the string stays lowercase), but doing it manually across a large list of names is where errors accumulate. It is useful before writing migrations, route handlers, or config loaders.

Where kebab-case slugs map to snake_case identifiers

Python web frameworks like FastAPI and Django map URL path parameters to function arguments.¹ A route like "/user-profile/{id}" needs a Python handler function whose parameter names match,and Python requires snake_case for function parameters.² This naming boundary appears in every full-stack application that serves kebab-case URLs to users while running Python code on the server side.

Route parameters and configuration keys

Python web frameworks like FastAPI and Django map URL path parameters to function arguments by name. A route like "/user-profile/{id}" needs a Python handler function whose parameter names match the URL segments, and Python requires snake_case for function parameters.² Building on this, configuration management tools like Ansible and Terraform use kebab-case keys in their YAML configuration files but map those keys to snake_case Python variables when accessed programmatically in application code. Kubernetes ConfigMap keys, Helm chart values, and Docker Compose environment variable names all use kebab-case in their source files, and the Python code that reads them needs snake_case variable names to follow PEP 8. When you generate Python configuration classes from a kebab-case YAML schema, converting the key names to snake_case before writing the class definition ensures the Python code is idiomatic from the start.

A consistent naming rule also keeps configuration code reviewable. When every Python variable that came from a kebab-case YAML key follows snake_case, a reviewer scanning a config loader sees one convention and can focus on the values rather than the spelling. Tools that read Kubernetes ConfigMaps or Helm values into Python objects expect the snake_case form, so generating the variable names from the kebab-case source before writing the loader is faster than hand-mapping each key. The result is config code that reads like the rest of the Python module instead of mixing two separator styles in the same function.

Edge cases: leading hyphens, numbers, and double hyphens

Leading hyphens in the input (from CSS custom property names with the two-hyphen prefix) strip the leading hyphens and produce "font_size". Double hyphens collapse to a single underscore: "my-double-hyphen-variable" becomes "my_double_hyphen_variable". Numbers maintain their position: "address-2" becomes "address_2". Yet if the kebab-case string contains an uppercase letter, which is non-standard, the output is still lowercase. PascalCase segments within kebab-case input, like "fontSize-body", also split at their camelCase boundary and produce "font_size_body", so mixed input needs no cleanup first. Empty lines pass through unchanged, and consecutive hyphens of any length collapse to a single underscore, so malformed input with triple or quadruple hyphens still produces valid output.

Workflow: converting URL slugs to Python function parameters

Building on this, when you are writing a Python API client and have a list of REST endpoint paths, paste the path segments (without the slashes) into this converter to get the corresponding Python parameter names. "user-profile" → "user_profile", "order-line-item" → "order_line_item". CapyToolkit converts each line independently, making bulk conversion of a full endpoint list straightforward. For FastAPI applications, the path parameter names in your route decorators must be snake_case to match Python conventions. When you design your API URLs in kebab-case (following Google's URL guidelines) but need snake_case parameter names in your Python handler functions, this converter bridges the gap. Paste all your planned URL path segments, copy the snake_case output, and use those names directly in your function signatures without manual re-typing.

FastAPI path parameter extraction and snake_case function argument naming

FastAPI automatically extracts path parameters from route definitions and maps them to function arguments by name.¹ The function parameter name must be snake_case to match the Python naming convention. When you design route paths with path parameters, the parameter names in curly braces must use snake_case in the function signature.

A FastAPI route like @app.get("/user-profile/{user_id}") has a kebab-case path segment and a snake_case path parameter. The function receives user_id: int because FastAPI matches path parameters by name. Route segment names (the static parts like user-profile) use kebab-case; parameter names (the parts in curly braces like {user_id}) use snake_case. Running your planned route path parameters through the converter gives you snake_case parameter names for your handlers before you write the function signature.

FastAPI query parameter naming and Pydantic model binding

FastAPI query parameters also use snake_case function parameter names. A request to /users?page_size=10 binds to a function parameter named page_size: int. If you design your API URLs using kebab-case query parameter names (e.g., page-size), you must either define an alias or use snake_case consistently in the URL. Paste your planned query parameter names into this converter to see the snake_case function argument names before writing the route handler.

Converting Ansible role names and Kubernetes ConfigMap keys to Python variables

Ansible role names use kebab-case by the Ansible Galaxy convention: my-database-role, nginx-proxy-config.³ Inside a role's tasks and variable files, variable names use snake_case. Kubernetes ConfigMap keys can use any format, but when Python code reads those values and assigns them to variables, the variable names follow snake_case.⁴ The ConfigMap keys themselves are constrained to alphanumeric characters, hyphens, underscores, and dots, so a kebab-case key such as max-file-size is legal to store and simply needs renaming on the Python side. Converting between these formats is a frequent task in infrastructure codebases that span provisioning tools and application runtime, and doing it consistently prevents the subtle naming mismatches that pass through code review unnoticed.

Ansible Galaxy role names appear in requirements.yml with kebab-case: role: geerlingguy.postgresql.³ Inside the role, variables like postgresql_version, postgresql_max_connections, and postgresql_listen_addresses use snake_case. When you reference a Galaxy role's variables from your own playbook, you use the snake_case names directly. This pattern repeats across every Ansible role you install from Galaxy: the role directory name uses kebab-case, but every variable you set or override within that role uses snake_case, making the conversion between the two formats a routine step when writing playbook variable overrides.

Terraform module output naming and Python consumption

Terraform module outputs use snake_case: output "database_url" { value = ... }.⁵ Terraform exposes output values to parent modules, the CLI, remote state readers, and automation tools, which is why automation scripts commonly read them by name.⁵ When a Python automation script reads Terraform outputs using the AWS SDK or the python-terraform library, the output name database_url maps directly to a Python variable name by convention. Paste your Terraform output names (which may come from a Kubernetes or Helm naming scheme using kebab-case) into this converter to get the snake_case equivalents for your Python automation scripts. CapyToolkit processes each line independently.

When to use this

Use this when mapping URL path segments to Python function parameters, converting CSS custom property names to Python config keys, or translating kebab-case API field names to snake_case database column names.

Examples

user-profile
order-history
payment-summary
account-settings

user_profile
order_history
payment_summary
account_settings

background-color
font-size-large
border-radius

background_color
font_size_large
border_radius

Convert PascalCase to snake_case

PascalCase class names and TypeScript interfaces need to map to snake_case database tables and Python model attributes. "UserProfile" maps to "user_profile", "OrderLineItem" maps to "order_line_item". When you have a schema with dozens of types, this conversion is too error-prone to do manually.

Building on this, the tool splits on every camelCase boundary (the uppercase letter that starts each word) and joins the resulting tokens with underscores in lowercase. It also gives you a reliable list for migrations, models, and API mappings.

When PascalCase meets snake_case in your stack

C# uses PascalCase for all types, methods, and properties per the Microsoft Coding Conventions.¹ Python uses snake_case for variables, functions, and class attributes per PEP 8.² Consequently, when you write a Python client for a C# API (or a Django model that mirrors a C# data contract), every name needs to cross this boundary. TypeScript interfaces also use PascalCase³ and must map to PostgreSQL column names (snake_case) through ORM layer code. Java, Kotlin, and Scala follow the same PascalCase convention for type names, which means this conversion applies at every boundary where a JVM or .NET type name enters a Python or SQL context. gRPC service definitions that serve both C# and Python clients need this conversion on one side or the other to keep the generated code idiomatic in each language.

Edge cases: acronyms and multi-word type names

Acronyms embedded in PascalCase types (like "HTTPRequest" or "UserAPIKey") stay together as one word: "HTTPRequest" becomes "http_request" and "UserAPIKey" becomes "user_api_key". Two-letter acronyms like "ID" in "UserID" work the same way and produce "user_id", the same result "HttpRequest" and "UserId" give. Numbers inside PascalCase names act as word boundaries: "Form2Submit" becomes "form_2_submit" and "V2Api" becomes "v_2_api". Single-word PascalCase types like "UserProfile" convert cleanly to "user_profile" because the splitter correctly identifies the word boundary between the lowercase prefix and the uppercase second word. When your PascalCase input already contains underscores (which is non-standard), the underscores are preserved as word boundaries alongside the camelCase splits.

Workflow: mapping TypeScript DTOs to Python dataclass fields

Building on this, here is the pattern: copy your TypeScript interface names, one per line, paste into this converter, and copy the snake_case output. Use those names as your Python dataclass class names or attribute groups. CapyToolkit converts each line independently, so a full DTO schema with 20 types processes in one pass.

For SQLAlchemy models, the snake_case class name maps to a snake_case table name by default when you set __tablename__ explicitly or rely on SQLAlchemy's naming convention. When both the TypeScript interface and the Python model share the same base name in their respective conventions, the API contract becomes self-documenting: a developer reading either codebase can trace field names across the boundary without a mapping table. For Pydantic v2 models consumed by FastAPI, the snake_case attribute names serialize to snake_case JSON keys by default⁴, which matches what the TypeScript DTO expects when the frontend sends data back. The same snake_case output also gives you the Alembic migration column names directly, so your database schema and your Python model stay in lockstep without a separate renaming step.

Generating Alembic migration column names from PascalCase C# class members

Alembic is the database migration tool for SQLAlchemy applications. Column names in Alembic migrations are snake_case by convention, matching the Python attribute names on SQLAlchemy ORM models.⁵ When you design a Python schema that mirrors a C# data model, converting the C# PascalCase property names to snake_case before writing the migration file prevents naming inconsistencies.

Alembic's op.add_column() function takes the table name and a sa.Column() with the column name as a string. That string must be snake_case to match the SQLAlchemy model attribute. Paste your C# class property names in to keep model and migration column names aligned, then use the snake_case output in both your Alembic migration file and your SQLAlchemy model definition simultaneously.

When the model definition and the migration file drift apart by even a single column name, the ORM layer produces queries that reference a column the database does not have. The resulting error only appears at runtime, not at import time, which makes it tedious to track down in a codebase with dozens of models.

Planning migrations before code review

Alembic's autogenerate mode compares the current SQLAlchemy model definitions against the database schema and generates the migration diff automatically. For autogenerate to work correctly, the column names in the model must match the column names already in the database. If your previous migration used PascalCase column names (non-standard), autogenerate will propose renaming them. Paste the existing column names into this converter to see the correct snake_case equivalents before deciding whether to add a renaming migration step.

Running the converter during the planning phase also makes code review faster. A reviewer who sees snake_case column names in both the model and the migration file knows at a glance that the two are in sync, without tracing each name back to its C# source. Catching a casing mismatch before merge is far cheaper than discovering it after the migration has already applied to a shared staging database. The deterministic output means the same source property always maps to the same column name, so the review is purely a consistency check rather than a recomputation.

Handling C# acronym naming in snake_case output

C# types often contain acronyms like "HTTPRequest" or "UserAPIKey". When converting these to snake_case, the converter keeps each acronym together and splits where the next word starts: "HTTPRequest" becomes "http_request" and "UserAPIKey" becomes "user_api_key". Those names read naturally in Python and in database columns, so you can paste C# member names as they are. The same rule covers any multi-letter acronym: "XMLParser" and "XmlParser" both become "xml_parser".

Django model verbose_name fields and snake_case display naming

Django model verbose_name fields provide human-readable display names for model fields in the Django admin and in form labels. While the model attribute uses snake_case, the verbose_name is a display string written in lowercase following Django's conventions.⁶ Django's convention is to write verbose_name as a lowercase string without any prefix capitalization such as verbose_name="user profile", and Django admin capitalizes the first letter automatically in the UI without any extra configuration on your part. The conversion from a C# PascalCase property to a Django_admin-friendly display name is a deliberate two-step process: first convert to snake_case with this tool, then replace underscores with spaces for the verbose_name value.

Batch generating Django field definitions from a C# class is straightforward when you paste all the property names into this converter at once to get the snake_case attribute names. A property like FirstName produces the snake_case attribute first_name and the verbose name "first name" after replacing underscores with spaces. CapyToolkit converts each line independently, so generating attribute names for a 30-field class takes one paste. Write the verbose_name strings separately after replacing underscores with spaces.

Batch generating Django field definitions

When you have a C# class with PascalCase properties and need to write a Django model that mirrors it, paste all the property names into this converter to get the snake_case attribute names. A property like FirstName produces the snake_case attribute first_name and the verbose name "first name" (after replacing underscores with spaces). CapyToolkit converts each line independently, so generating attribute names for a 30-field class takes one paste. Write the verbose_name strings separately after replacing underscores with spaces.

When to use this

Use this when writing Python model classes that mirror C# or TypeScript types, generating PostgreSQL table names from class names, or mapping a PascalCase schema to a snake_case one.

Examples

UserProfile
OrderLineItem
PaymentMethod
ShippingAddress

user_profile
order_line_item
payment_method
shipping_address

ProductCatalog
InventoryItem
PriceHistory

product_catalog
inventory_item
price_history

Convert Text to kebab-case

Kebab-case is common for CSS property names, CSS custom properties with a two-hyphen prefix, HTML data- attributes, URL slugs, and many CLI flag names. Converting a camelCase component name or a Title Case heading to kebab-case by hand is error-prone when you have many to process.

Where kebab-case is the required format

CSS property names and at-rule names are ident sequences that can include hyphen-minus, and common CSS declarations such as background-color and font-family use hyphenated names¹. CSS custom properties use names with a two-hyphen prefix, such as two-hyphen-example-name, and are referenced with var()². HTML data-* attributes start with data-; MDN recommends lowercase names and shows kebab-case names such as data-test and data-test-abc³. For URLs, Google recommends using hyphens instead of underscores to separate words because they help users and search engines identify concepts⁴. Many command-line tools also expose long options with two leading hyphens, such as dry-run or output-dir⁵.

Why kebab-case is not valid in JavaScript

In JavaScript, a hyphen is the subtraction operator, so my-variable is parsed as subtraction rather than as a single identifier⁶. That is why kebab-case is useful for CSS, HTML attributes, URL paths, and CLI long-option names, but not for JavaScript or TypeScript variable names. The same restriction applies to Python, Java, C#, and virtually every language that uses hyphen as an arithmetic operator. When you need to reference a kebab-case name in JavaScript code, you must use bracket notation: element.style["background-color"] or obj["my-property"] instead of dot notation. The browser's dataset API works around this limitation by automatically converting kebab-case HTML attribute names to camelCase JavaScript properties: data-user-id becomes dataset.userId. CSS custom property access through getPropertyValue and setProperty also requires the exact kebab-case name, including the two-hyphen prefix, because the CSSOM treats custom property names as case-sensitive strings.

Workflow: naming CSS custom properties from a design token list

Design tokens often arrive from design tools as camelCase keys, but CSS custom properties need kebab-case names. When you have a design token export from Figma or a tokens.json file, paste all the token names into this converter, copy the kebab-case output, and add the two-hyphen prefix for each CSS custom property.

From design tokens to :root declarations

Design tokens from Figma or a tokens.json file often use camelCase keys like "colorPrimary", "spacingMd", or "fontSizeBody". CSS custom properties, on the other hand, follow kebab-case naming after the two-hyphen prefix. "colorPrimary" becomes "color-primary", which you then reference with the var() function and the two-hyphen prefix in your stylesheets. CapyToolkit converts each line independently, so a full design token set processes in one pass and gives you the CSS variable names ready to insert into a :root block without manual renaming.

The benefit is a single source of truth for token names. When the design file changes, you regenerate the kebab-case list and the stylesheet variables track it without hand editing each name. You can preview the mapping in CapyToolkit by pasting your token keys and converting them, then checking that every output matches the custom property your CSS already references.

BEM naming methodology and kebab-case class structure in CSS

BEM (Block Element Modifier) is the most widely adopted CSS class naming methodology. All BEM identifiers use kebab-case for multi-word segments, making this converter a direct tool for naming BEM components from camelCase or PascalCase source identifiers. When a team adopts BEM without a consistent kebab-case convention, class names drift into mixed formats that break the pattern matching developers rely on when searching for component styles across a large codebase.

BEM class names follow the pattern block__element-modifier. The block, element, and modifier segments are each kebab-case when they contain multiple words: .navigation-bar, .navigation-bar__menu-item, .navigation-bar__menu-item-active. When you have a camelCase component name from a JavaScript file, paste it into this converter to get the BEM block name before writing the stylesheet. "navigationBar" becomes "navigation-bar", which becomes .navigation-bar as the root class.

Stylelint BEM enforcement

Stylelint's selector-class-pattern rule accepts a regex that every class name must match. A BEM-aware pattern can permit the element delimiter and a modifier suffix while ensuring all segments are kebab-case. Add this rule to your .stylelintrc to catch any class that uses camelCase, underscores outside the BEM delimiter, or uppercase letters. Running Stylelint in CI prevents BEM violations from merging and keeps class names consistent across large stylesheets authored by multiple contributors.

Generating kebab-case slugs for Hugo and Jekyll content paths

Static site generators like Hugo and Jekyll derive URL paths from content file names. File names use kebab-case by convention, and the content path becomes the page URL. Generating kebab-case file names from article titles before creating content files prevents URL mismatches and avoids slug normalization issues after publishing. A title typed with spaces or uppercase letters produces a URL that looks unprofessional and may not match the canonical link you share on social media, which splits search engine signals across two different URLs for the same content.

Hugo expects content files in kebab-case for clean URLs without configuration overrides. A post titled "Getting Started With TypeScript Generics" should use the file name getting-started-with-typescript-generics.md. Paste the title in to hyphenate a title into a clean slug and copy the kebab-case result as the file name, joining "type-script" back into "typescript", since the converter splits mixed-case words such as TypeScript at their capital letter. The URL the site generates matches the file name directly, which means no mismatch between what you type in the terminal and what appears in the browser. Getting the name right on the first try saves you from renaming files and updating internal links across a content tree that may already have been indexed.

Jekyll permalink configuration and slug generation

Jekyll derives the slug from the file name by default, stripping the date prefix. A file named 2026-06-01-my-post-title.md produces the slug my-post-title. When you configure custom permalinks with :slug, the value must be kebab-case for readable URLs. Paste your article title into this converter before naming the file and you avoid the common error of a title with spaces or uppercase letters producing an unusable slug. CapyToolkit processes each line independently, so a batch of planned post titles converts in one pass and every planned path follows the same consistent kebab-case convention from the start

When to use this

Use this when generating URL slugs from article titles, naming CSS custom properties from a design token list, or mapping JavaScript variable names to HTML data attributes.

Examples

How to Convert camelCase to snake_case
Best Practices for API Design
Getting Started With TypeScript

how-to-convert-camel-case-to-snake-case
best-practices-for-api-design
getting-started-with-type-script

primaryColor
borderRadius
fontSizeLarge

--primary-color
--border-radius
--font-size-large

Convert camelCase to kebab-case

Design systems often expose token names as camelCase JavaScript keys, but CSS and HTML need kebab-case equivalents. When you map those names to CSS custom properties or HTML data attributes, you need to convert the format.

Yet hyphens are subtraction operators in JavaScript, TypeScript, Python, and Java. Consequently, kebab-case is not valid in those languages as an identifier: it only appears in CSS, HTML attributes, URL slugs, and CLI flags.¹

Where camelCase identifiers need kebab-case equivalents

CSS custom properties use a two-hyphen prefix followed by kebab-case names, such as a property named background-color after the prefix. When a design system exports tokens as JavaScript object properties (backgroundColor, fontSizeLarge), the CSS variable equivalents require kebab-case names. HTML data attributes also require kebab-case: data-user-id, data-product-name.² The same rule applies to SVG attributes presented as kebab-case in markup, since presentation attributes like stroke-width and fill-opacity follow the same hyphenated convention across the entire document object model.

CSS custom properties and data attributes

CSS custom properties use a two-hyphen prefix followed by kebab-case names, such as a property named background-color after the prefix. When a design system exports tokens as JavaScript object properties like "backgroundColor" or "fontSizeLarge", the CSS variable equivalents require kebab-case names. HTML data attributes follow the same convention: "data-user-id" and "data-product-name" are kebab-case, even though the corresponding JavaScript dataset properties use camelCase. Building on this, CLI tools and npm scripts commonly use kebab-case flags, which correspond to camelCase options in the underlying configuration objects.

The reverse mapping also happens constantly in JavaScript. When you read a data-user-id attribute through the DOM dataset API, the browser hands your code the camelCase key userId, so the kebab-case source and the camelCase key are two views of one attribute. Keeping both names derived from the same token prevents the mismatch where a CSS file declares --user-id but the script reads dataset.userId with a different casing. Design systems that document their tokens once and generate both the CSS variables and the dataset keys from that source avoid maintaining two name lists that can drift apart.

Edge cases: acronyms, numbers, and consecutive capitals

Acronyms stay together as one word: "parseHTML" becomes "parse-html". Numbers act as word boundaries: "h1Tag" becomes "h-1-tag". Consecutive capitals that form an acronym, like the "HTTP" in "parseHTTPResponse", split where the next capitalized word begins, so the result is "parse-http-response", the same as for "parseHttpResponse". HTML element references like "h1Heading" produce "h-1-heading", so rejoin the number by hand if your class names keep it attached. Strings that mix both acronym styles, such as "XMLHttpRequest", still come out readable as "xml-http-request". Empty lines and whitespace-only lines pass through unchanged, so formatting a multi-line paste with blank separators between logical groups does not produce unwanted hyphens.

Workflow: converting design token names to CSS variables

Building on this, a practical workflow: your design system defines tokens as JavaScript constants,colorPrimary, spacingMd, fontSizeBody. To write a CSS file with custom properties, paste all the constant names into this converter and copy the kebab-case output. Each name becomes a CSS custom property name: color-primary, spacing-md, font-size-body. Add the two-hyphen prefix and you have your :root declarations. CapyToolkit converts each line independently. When tokens come from a tool like Figma or Tokens Studio, the export format may use camelCase or dot-separated paths. Converting the exported names to kebab-case before writing them into your stylesheet ensures they match CSS custom property naming rules. For design systems that support multiple themes, prefixing the kebab-case output with a theme segment (dark-color-primary, light-color-primary) creates self-documenting variable names that developers can search for across the entire codebase.

Vue.js component props: camelCase in JavaScript and kebab-case in templates

Vue.js distinguishes between camelCase and kebab-case at the component boundary. JavaScript component options use camelCase for prop names; Vue template syntax requires kebab-case for the same props. Converting between these two formats is the most common Vue naming task when building reusable components, and this converter handles the split cleanly for any prop list you paste into the input field.

A Vue component defined with props: { userId: String, firstName: String } uses camelCase internally. In a parent template, you reference those props with kebab-case attributes: <UserCard :user-id="id" :first-name="name" />. Vue's template compiler handles this conversion automatically for HTML attribute syntax, but understanding the mapping prevents confusion when reading templates that use kebab-case prop names for props defined as camelCase in the component options.³

Converting prop names for v-bind and dynamic bindings

Dynamic bindings in Vue with v-bind or : shorthand follow the same kebab-case requirement in HTML templates. If you have a camelCase list of prop names from a component interface and want to write the template binding attribute names, paste them into this converter and use the kebab-case output in the template. "borderRadius" becomes "border-radius" as an attribute in the template. For Composition API components using defineProps, the camelCase names are used in the <script setup> block and the kebab-case equivalents in the template.

Generating Tailwind CSS utility class names from design token identifiers

Tailwind CSS generates utility class names from its configuration object, which uses camelCase keys. When you extend Tailwind's theme or add custom utilities, the configuration uses camelCase, but the resulting class names in HTML templates use kebab-case. Converting your camelCase token names to kebab-case before checking the generated class name helps verify your configuration is correct.

A Tailwind theme extension like theme: { extend: { fontSize: { bodyLarge: '18px' } } } generates the class text-body-large. The camelCase key bodyLarge becomes the kebab-case class suffix body-large.⁴ Paste your camelCase token key names in to check the class suffix Tailwind builds before adding them to the configuration. This prevents surprises where the class name you expect does not match what Tailwind generates.

JIT mode and dynamic class name generation

Tailwind's JIT (just-in-time) mode scans your template files for class names and generates only the CSS that is actually used. Dynamic class name construction like `text-${size}` does not work because JIT cannot detect string-concatenated class names at build time. You must write the full class name as a static string. Converting your token identifiers to kebab-case and writing the full class names statically in your template files ensures JIT generates the correct CSS.⁴ CapyToolkit converts each line independently, so checking a full design token list takes one paste.

Under the hood those tokens live in theme variables grouped into namespaces such as --color-*, --text-*, and --spacing-*, and every namespace maps to a matching set of utility classes.⁵ That is why a kebab-case token name is a safe prediction: convert textBodyLarge to text-body-large and you have the suffix Tailwind expects on a text-* utility.

When to use this

Use this when converting JavaScript design token names to CSS custom properties, mapping camelCase prop names to HTML data attributes, or generating kebab-case URL slugs from JavaScript identifiers.

Examples

colorPrimary
spacingMd
fontSizeBody
borderRadius

color-primary
spacing-md
font-size-body
border-radius

userId
productName
categoryId

user-id
product-name
category-id

Convert snake_case to kebab-case

Before Python names become URLs, CSS properties, or CLI flags, their separator needs to change. Python variable names (snake_case) map to URL slugs (kebab-case). Database column names (snake_case) map to CSS custom properties (kebab-case). Getting this separator swap right across a large set of names is exactly what this tool handles.

Yet this is not just a find-and-replace for underscores. The converter lowercases the full string and collapses consecutive separators before joining with hyphens.

Where snake_case names need kebab-case equivalents

Google's URL guidelines recommend hyphens as word separators in URLs rather than underscores, because search engines treat hyphens as word boundaries but not underscores.¹ Consequently, if your database stores article slugs in snake_case, converting them to kebab-case before rendering URLs improves search visibility. This separator swap also applies to CSS custom property names, which require kebab-case after the double-hyphen prefix, and to CLI flags that follow the GNU convention of hyphen-separated long options.

URL slugs and CSS custom properties

Google's Search Central documentation states that hyphens in URLs are treated as word separators, while underscores are not. This means a URL like "/new-york-city" is indexed as three separate tokens, whereas "/new_york_city" may be indexed as a single token. CSS custom properties also use kebab-case after the two-hyphen prefix, so a Python configuration key like "max_file_size" becomes "max-file-size" as the CSS variable name.² Converting your snake_case names to kebab-case before using them as URL slugs or CSS variable names ensures consistency across your project.

Applying the same conversion at both ends of a name keeps a project consistent without a lookup table. A slug stored in the database, the URL rendered in the browser, and the CSS variable referenced in the stylesheet can all derive from one kebab-case value. When a new route or token is added, generating its kebab-case form once and reusing it everywhere prevents the drift where the database holds snake_case, the URL shows kebab-case, and the stylesheet expects yet another spelling. That single source of truth is what makes a rename safe to apply across the stack.

Edge cases: uppercase, consecutive underscores, and numbers

SCREAMING_SNAKE_CASE input,like "MAX_FILE_SIZE",converts to "max-file-size" (lowercased and hyphens substituted). Consecutive underscores ("first__name") collapse to a single hyphen: "first-name". Numbers maintain their position: "address_2" becomes "address-2". Yet if a snake_case name contains a hyphen,which it should not by convention,the hyphen is also treated as a separator. PascalCase input like "UserProfile" converts to "user-profile" because the splitter detects camelCase boundaries before replacing separators. Mixed-format input from multiple sources, such as a configuration file that mixes SCREAMING_SNAKE keys with regular snake_case keys, normalizes to a consistent kebab-case output. Empty lines pass through unchanged, so pasting a list with blank separators between groups does not produce unwanted hyphens or empty segments.

Workflow: converting a Python route registry to URL slugs

Building on this, if your Python Flask or Django routes use snake_case function names and you want to generate the corresponding URL paths, paste the function names into this converter and copy the kebab-case output as your URL segments. "user_profile" becomes "user-profile", "order_history" becomes "order-history". CapyToolkit processes each line independently. For Django REST Framework viewsets, the basename in your URL configuration often derives from the model name in snake_case. Converting it to kebab-case before registering the route produces clean, readable URLs that follow Google's recommendation for hyphen-separated path segments. When you migrate an existing API from snake_case URL segments to kebab-case, running the old segment names through this converter gives you the exact mapping for your 301 redirect rules, ensuring existing bookmarks and external links continue to resolve.

Google Search's treatment of URL word separators for indexing

Google Search treats hyphens and underscores differently when indexing URLs, which has direct SEO implications for pages whose slugs come from snake_case database fields or Python route identifiers. When a URL path uses underscores to separate words, Google may not recognize those words as individual tokens during indexing, reducing the page's relevance for multi-word search queries. Converting snake_case slugs to kebab-case before they reach the browser ensures each word in the path contributes to the page's search profile.

Google's Search Central documentation states that hyphens are treated as word separators in URLs, while underscores are not.¹ A URL like /new-york-city is indexed with three separate tokens: "new", "york", "city". A URL like /new_york_city is indexed as a single token "newyorkcity" in some contexts. For competitive keywords where individual word matching matters, hyphens produce more accurate indexing. This matters most for long-tail URLs built from database slugs that were originally stored as snake_case.

URL normalization in existing Python codebases

Django's slug fields default to snake_case for legacy reasons in some codebases. Converting existing slug fields to kebab-case requires a migration that updates the stored values, plus 301 redirects from the old snake_case URLs to the new kebab-case ones. Before starting that migration, paste a sample of your existing slugs in to see how each underscore becomes a hyphen and confirm the conversion produces valid, readable URLs. CapyToolkit processes each line independently, so testing a batch of existing slug values takes one paste. Run the migration only after confirming the output looks correct for all edge cases in your slug set, including slugs that contain numbers, consecutive underscores, or uppercase letters that appear in older database records.

Ansible and Kubernetes YAML variable naming across kebab-case and snake_case

Ansible uses snake_case for variable names in playbooks and roles.³ Kubernetes YAML uses kebab-case for resource label keys and some annotation keys.⁴ When you share configuration values between Ansible provisioning and Kubernetes manifests, you encounter both naming formats in the same infrastructure codebase. This naming mismatch appears most often when Ansible defines infrastructure parameters that Kubernetes consumes as labels or selectors, forcing you to maintain a consistent mapping between the two separator styles across your deployment pipeline.

Ansible variable names in defaults/main.yml files are snake_case: database_url, replica_count, max_memory_mb. Kubernetes label keys in metadata.labels use kebab-case: app.kubernetes.io/name, component: database-primary. The same conceptual value often appears in both places with different separator characters, requiring a consistent conversion strategy. When you paste Ansible variable names into this converter, you get the exact kebab-case equivalents that Kubernetes expects, eliminating the manual separator substitution that introduces typos in infrastructure-as-code repositories.

Helm chart values and naming conventions

Helm chart values.yaml files use camelCase for user-configurable values by the Helm community convention, but the rendered Kubernetes YAML uses kebab-case label keys.⁵ Helm's own guidance goes further and tells chart authors not to put hyphens in value keys at all, because Go templates parse a hyphen as subtraction, so dashed keys require the index function to read.⁵ When your Helm templates read Ansible-generated configuration and render it into Kubernetes labels, the conversion from snake_case Ansible variables to kebab-case label values must happen in the template. Paste your Ansible variable names into this converter to preview the kebab-case label values before writing the Helm template logic. CapyToolkit processes each line independently.

When to use this

Use this when converting Python variable names to URL slugs, transforming database column names to CSS custom property names, or mapping snake_case config keys to kebab-case CLI flags.

Examples

user_profile
order_history
payment_summary
account_settings

user-profile
order-history
payment-summary
account-settings

background_color
font_size_large
border_radius

background-color
font-size-large
border-radius

Convert Anything to CONSTANT_CASE

For values that never change at runtime, CONSTANT_CASE makes the intent visible immediately. Python constants, JavaScript config flags, C preprocessor macros, and environment variables all follow this pattern.

This tool converts any input (camelCase, PascalCase, kebab-case, or spaces) to CONSTANT_CASE by splitting on all word boundaries and joining with underscores in uppercase.

Where CONSTANT_CASE is used

Python uses SCREAMING_SNAKE_CASE for module-level constants, as specified in PEP 8.¹ JavaScript and TypeScript use it for compile-time constants and immutable config values, per the Google JavaScript Style Guide.² C and C++ preprocessor macros are written in SCREAMING_SNAKE by the GNU Coding Standards.³ Furthermore, all environment variables passed to Docker containers, shell scripts, or CI systems use this format: DATABASE_URL, SECRET_KEY, MAX_RETRIES.⁴ AWS Systems Manager Parameter Store paths, Azure App Configuration keys, and Google Cloud Secret Manager secret names all follow CONSTANT_CASE by convention. Even in languages that do not enforce it at the compiler level, like Ruby (which uses SCREAMING_SNAKE for constants as a community convention), the pattern signals immutability to anyone reading the code.

Edge cases: acronyms, mixed inputs, and single-word values

When an input already contains uppercase letters, like "parseHTML", the splitter separates on camelCase boundaries and produces "PARSE_HTML". Numbers act as word boundaries: "retryAfter3Seconds" becomes "RETRY_AFTER_3_SECONDS". Yet single-word inputs like "timeout" convert simply to "TIMEOUT" with no underscores added. Empty lines pass through unchanged, making it safe to paste a block of mixed declarations. Mixed separator inputs like "my-mixed_separator" produce "MY_MIXED_SEPARATOR", correctly handling the case where configuration keys from different sources use different separator conventions. PascalCase class names like "UserProfile" convert to "USER_PROFILE", which is the standard format for feature flags or permission names derived from class identifiers. SCREAMING_SNAKE input that is already in the target format passes through unchanged, so re-converting an already-formatted list is safe.

Workflow: converting a .env template to exported constants

Building on this, a common pattern is to draft new environment variable names in camelCase during development (since most code editors autocomplete camelCase identifiers), then convert the entire list to CONSTANT_CASE before adding them to a .env file or a configuration module. Paste all the camelCase names at once, copy the CONSTANT_CASE output, and you have the canonical variable names for documentation, CI configuration, and the application code simultaneously.

.env templates from camelCase drafts

When drafting new configuration entries, developers often start with camelCase names in source code. Converting those drafts to CONSTANT_CASE gives you the canonical environment variable names that belong in your .env file. Use the output as the single source of truth for both your .env template and your application config module so the names stay consistent across documentation, CI configuration, and the running application before code review.

The single source of truth approach removes a frequent source of bugs. When the .env template, the config module, and the docs all derive their names from one converted list, a typo cannot hide in just one of them. You can generate that list in CapyToolkit by pasting your camelCase drafts and converting them, then copying the output into each location so the casing stays identical everywhere.

Environment variable naming in .env files and the dotenv specification

The .env file format originated with the Ruby dotenv gem⁵ and became the standard for twelve-factor application configuration across all languages. Every key in a .env file follows CONSTANT_CASE by convention, though the format itself does not enforce it. Libraries like python-dotenv, Node.js dotenv, and the Go godotenv package parse the file without casing validation, which means inconsistently named keys silently coexist.

Validation at the application startup level catches naming inconsistencies before they cause runtime surprises. The Python pydantic-settings library reads environment variables into a Pydantic model where field names must match the variable names, with an option for case-insensitive matching. The Node.js envalid library provides explicit spec-declaration for each required variable, raising errors at startup for missing or incorrectly named variables.

Validation at application startup

pydantic-settings v2 maps environment variables to model fields using the env parameter or by convention: a field named database_url reads DATABASE_URL from the environment. Configuring env_prefix = "APP_" on the SettingsConfigDict means APP_DATABASE_URL maps to database_url. Run the app with missing variables to confirm the error message names the missing key in CONSTANT_CASE. This makes debugging environment configuration much faster than discovering a missing variable only after a specific code path executes.

Terraform variable naming: HCL inputs versus CONSTANT_CASE environment overrides

Terraform uses lowercase snake_case for variable names in HCL configuration files. However, when you override those variables using environment variables (the TF_VAR_ prefix), the environment variable uses TF_VAR_ in uppercase followed by the lowercase snake_case variable name.⁶ This two-format system trips up developers who expect the same casing in both places.

A Terraform variable declared as variable "database_url" {} is overridden by the environment variable TF_VAR_database_url. Note that the TF_VAR_ portion is uppercase but the variable name segment stays lowercase, unlike the CONSTANT_CASE convention used for other environment variables. Knowing this distinction prevents mistakes when you use this converter to generate environment variable names for Terraform overrides.

AWS Systems Manager Parameter Store and CONSTANT_CASE paths

AWS SSM Parameter Store paths often use CONSTANT_CASE for the leaf parameter name segment: /myapp/production/DATABASE_URL. Applications that read parameters from SSM at startup must request the exact path, and the leaf name must match the expected environment variable name exactly. Paste your planned environment variable names into this converter before registering them in SSM and in your .env files to ensure both sources use consistent CONSTANT_CASE. Mismatches between SSM parameter names and application variable names are silent: the variable reads as undefined rather than raising an error.

When to use this

Use this when naming new environment variables, declaring Python module constants, or writing C preprocessor macros, and draft the env var names in CONSTANT_CASE before code review so the same spelling reaches your config module, your CI settings, and your documentation.

Examples

databaseUrl
secretKey
maxRetries
apiTimeoutMs

DATABASE_URL
SECRET_KEY
MAX_RETRIES
API_TIMEOUT_MS

default_page_size
max_upload_size_mb
allowed_hosts

DEFAULT_PAGE_SIZE
MAX_UPLOAD_SIZE_MB
ALLOWED_HOSTS

Convert Anything to dot.case

In JVM ecosystems and configuration hierarchies, dot.case gives each word its own segment. Java package names follow it (com.example.app), configuration file keys use it (server.port, spring.datasource.url), and Maven artifact IDs adopt it for group and package identifiers.

Yet dot.case does not appear in file system paths (that is path/case) or CSS (that is kebab-case). Its domain is configuration hierarchies and JVM ecosystem conventions. That keeps package and config names readable across nested layers.

Where dot.case is used

Java uses dot.case for package names, following the Java Language Specification convention of reversed domain plus package path: com.example.auth.¹ Spring Boot and other Java frameworks use dot-separated keys in application.properties: spring.datasource.url, server.servlet.context-path.² Maven and Gradle use it for group IDs: org.springframework.boot, io.micronaut.³ Furthermore, JavaScript config files like .npmrc and Webpack treat dot-separated keys as nested property paths. In the .NET ecosystem, namespace names follow dot.case: System.Collections.Generic, Microsoft.Extensions.Logging.⁴ Environment variable names in some Windows contexts use dot-separated hierarchies, though this is less common than underscores. Logging frameworks across languages (Log4j, Serilog, NLog) use dot-separated logger names that mirror the class hierarchy,⁵ making dot.case the standard for log configuration. The convention appears anywhere a hierarchical namespace needs a flat string representation that remains human-readable while preserving the nesting structure of the underlying system.

Edge cases: numbers, slashes, and existing dots

Numbers follow the same boundary rule as other case formats: "version2Release" becomes "version.2.release". Slashes and backslashes (present in file paths) are also treated as word boundaries and replaced with dots. Consequently, a filesystem path "com/example/auth" converts to "com.example.auth" correctly. Existing dots in the input are treated as separators rather than preserved as-is, which means re-converting an already dot.case string produces the same result. Windows-style backslash paths like "com\example\auth" convert identically to forward-slash paths, producing "com.example.auth" in both cases. Consecutive separators of any type (multiple dots, multiple slashes, or a mix) collapse to a single dot, so "com..example...auth" normalizes to "com.example.auth" without empty segments. CamelCase input within dot-separated segments, like "spring.data.mongodbUri", splits the camelCase portion and produces "spring.data.mongodb.uri". Handling all of these edge cases in a single pass is what makes the converter reliable when you are migrating a mixed-format configuration base to a consistent dot.case convention.

Workflow: converting a directory path to a Java package name

Building on this, here is the common workflow: you have a directory structure src/main/java/com/example/auth/service and want the package declaration. Paste the path segment "auth/service" or "com/example/auth/service" into the converter, and the dot.case output is your package name. The tool handles every segment of the path in one pass, so you get the fully qualified package name without manually replacing each separator character.

Package declarations from service paths

When you create a new Java package from an existing directory structure, the directory hierarchy becomes the package name with dots as separators. "auth/service" becomes "auth.service", and "com/example/auth/service" becomes "com.example.auth.service". Every subdirectory under the source root maps to a segment in the fully qualified package name, which means a deeply nested service class carries its entire ancestry in its package declaration. CapyToolkit processes each line independently, so converting multiple service paths in one pass produces a list of package names ready to use in import statements without manual renaming at each level.

The ancestry in the package name pays off when you read the code later. A developer scanning an import can tell exactly where a class lives in the source tree without opening the file. You can produce those import names in CapyToolkit by pasting your service paths and converting them, then copying the dot.case output straight into your Java files so the package and the directory agree.

Spring Boot application.properties key structure and dot.case conventions

Spring Boot's externalized configuration system reads application.properties files using dot-separated hierarchical keys. The key hierarchy mirrors Java package naming: spring.datasource.url, server.port, management.endpoints.web.exposure.include. When you add a new configuration property, choosing the correct dot.case key before writing it prevents refactoring later. Each layer of the hierarchy maps to a segment in the dot-separated key, so a deeply nested property like the health check endpoint path reads as a natural extension of the package structure it belongs to.

Spring's relaxed binding accepts underscores and hyphens as alternatives to dots in some contexts, but the canonical form in application.properties uses dots.² The Spring documentation lists all standard properties in dot.case, so matching that format makes it easier to search for the property in the documentation. Paste camelCase or snake_case property identifiers from your Java code in to get a Spring property key right before it reaches the application.properties file.

Converting Spring configuration keys between formats

Spring Boot applications frequently need the same configuration value in multiple formats across different layers of the application, and keeping those values synchronized by hand is a common source of deployment errors. A DATABASE_URL environment variable maps to spring.datasource.url in application.properties and to @Value("${spring.datasource.url}") in Java code. Converting between these three formats manually is error-prone because each layer expects a different separator convention. Paste the environment variable name, convert to dot.case, and use the output as both the application.properties key and the Spring @Value expression without any additional transformation. CapyToolkit processes each line independently, so converting a full set of database, cache, and queue configuration properties takes one paste.

Java logging framework configuration keys in dot.case

Java logging frameworks (Log4j 2, Logback, SLF4J) use dot-separated logger names derived from class names. Logger names follow the fully-qualified class name format: com.example.auth.UserService.⁵ Understanding this convention matters when configuring per-package log levels in logback.xml or log4j2.xml. The dot-separated hierarchy mirrors the Java package structure, so a logger configured at the com.example level applies to every class in that package and all its subpackages without needing individual entries for each class.

Logger configuration in Logback uses the name attribute on <logger> elements: <logger name="com.example.auth" level="DEBUG" />. This name must use dot.case matching the Java package structure. If your package is com.example.auth but you configure the logger as com-example-auth, the configuration is silently ignored and the logger falls through to the root level. Paste your Java package names into this converter to verify the dot.case format before writing logger configuration.

Logback XML configuration and logger naming

Logback's logback.xml supports package-hierarchy logger configuration: setting com.example to WARN suppresses debug output from all classes under that package. Adding a finer-grained com.example.auth logger at DEBUG re-enables debug logs for that specific package without affecting others. Getting the dot.case package name exactly right in the name attribute determines which classes the rule applies to, because a mismatched separator causes the configuration to be silently ignored. CapyToolkit converts each line independently, so converting an entire list of package names for a multi-module application takes one paste.

When to use this

Use this when writing Java package names from directory paths, generating Spring Boot property keys from camelCase method names, or formatting Maven artifact identifiers.

Examples

authService
userRepository
paymentGateway

auth.service
user.repository
payment.gateway

server_port
spring_datasource_url
app_jwt_secret

server.port
spring.datasource.url
app.jwt.secret

Convert Anything to path/case

When a name represents a hierarchy, path/case makes each word a segment. Filesystem paths, URL path segments, Go module import paths, and route pattern segments all follow this structure.

Yet path/case is not the same as a URL path. URL paths may include query strings, fragments, and protocol prefixes that this converter strips away. The output is the path segment format only, lowercase words joined by slashes.

Where path/case is used

Go module import paths follow path/case convention: "github.com/user/my-package" uses a mix of path segments.¹ HTTP URL path segments are lowercase and slash-separated, per Google's URL structure recommendations.² Filesystem paths on Linux and macOS are case-sensitive and commonly lowercase, making path/case the default for directory naming. Building on this, routing libraries like Express.js and FastAPI parse slash-separated URL segments, and matching those to code identifiers is cleaner when both follow path/case. REST API resource hierarchies map naturally to path/case, because the forward slash in a URI path marks a hierarchical relationship between resources: "/api/v1/order-line-items" represents a nested collection in a URL.³ AWS S3 object keys, Azure Blob Storage paths, and Google Cloud Storage prefixes all use forward-slash hierarchies, making path/case the standard for cloud storage organization. Even Windows file paths, which use backslashes internally, are often represented with forward slashes in cross-platform tools and configuration files.

Edge cases: existing slashes, uppercase, and empty segments

Existing forward slashes in the input are treated as word separators and do not get duplicated. Backslashes (Windows paths) are also treated as separators and replaced with forward slashes. Consecutive separators produce single slashes in the output, eliminating empty path segments. Consequently, converting "tools/Text/Case Converter" produces "tools/text/case/converter" without any double slashes or empty segments. CamelCase or PascalCase segments within an existing path, like "api/UserProfile/settings", split on word boundaries and produce "api/user/profile/settings". Leading slashes are dropped and numbers become their own segment, so "/api/V2/Errors" becomes "api/v/2/errors"; add the leading slash and rejoin "v2" by hand. Trailing slashes are stripped from the final segment, preventing empty path components that would cause routing mismatches. Mixed OS path notation like "src\main/java/com/example" normalizes to "src/main/java/com/example" with consistent forward slashes regardless of the original separator style. Handling all of these edge cases in a single pass is what makes the converter reliable when you are migrating a mixed-format directory structure to a consistent path/case convention.

Workflow: generating file paths from feature names

Building on this, a common use case: you have a list of feature module names in PascalCase and need to generate the corresponding directory paths. "UserAuthentication" becomes "user/authentication", "PaymentGateway" becomes "payment/gateway". This conversion is the first step when scaffolding a new project structure from a domain model: each entity or service name becomes a directory path that mirrors the conceptual hierarchy. Getting the paths right before scaffolding prevents a tangle of broken imports across dozens of files that would require a dedicated cleanup pass after the project structure changes.

Directory paths from module names

When organizing a codebase, module names in PascalCase or camelCase need to map to lowercase directory paths with forward slashes. "UserAuthentication" becomes "user/authentication", and "PaymentGateway" becomes "payment/gateway". CapyToolkit converts each line independently, so you can scaffold directory paths from module names in one pass. These paths map directly to Go import paths or URL routing segments. For monorepo setups using Nx or Turborepo, the library path in project.json or package.json follows the same convention: a library named "UserAuthentication" lives at "libs/user/authentication". Converting your planned library names to path/case before running the scaffolding command ensures the generated directory structure follows your naming convention from the start, which prevents a later refactor of import paths across dozens of files.

A single path generates from one module name in several downstream places: the directory on disk, the import statement in code, the route template in a web framework, and the documentation URL. Keeping every one of those derived from the same path/case value avoids the drift where the folder says one thing and the import says another. When the tool produces the path once, you can paste it into each location rather than retyping and risking a casing mismatch that a linter or the compiler later rejects.

Go module import paths and the GOPATH module naming conventions

Go module paths follow the path/case format exclusively. A module hosted at github.com/user/my-package uses a path-case module path, and every package inside it follows the same convention. Go's toolchain validates that import paths are valid URLs, which makes camelCase or PascalCase segments in the module path unusual and potentially problematic for tooling.

Go's standard library uses short, lowercase, single-word package names where possible: net/http, encoding/json, database/sql.⁴ Multi-word packages use lowercase without separators: crypto/tls, net/textproto. When you add a new package to a Go project, the path segment should be lowercase. Paste your planned package name from PascalCase or camelCase and copy the path.case output as the directory name and import path segment.

Package documentation URLs in pkg.go.dev

Go package documentation is hosted at pkg.go.dev/<module-path>/<package-name>. Uppercase letters in module or package paths create URLs that are technically case-sensitive and visually inconsistent with Go conventions. All major Go open source packages use entirely lowercase paths. Paste your module and package names into this converter before initializing the repository to verify the path.case format before the module path is set in go.mod. After running go mod init, changing the module path requires updating every import statement across the entire codebase, which is a time-consuming and error-prone process.

Express.js and FastAPI route naming conventions with path/case segments

Express.js and FastAPI both parse URL path segments as route parameters. The naming convention for those segments influences how you name the corresponding function parameters in your handler code, which should follow each language's own naming convention. Keeping the URL structure and the parameter naming format visually distinct prevents confusion when reading route definitions that span both the path template and the function signature in the same file.

Express.js uses kebab-case for static route segments by convention and camelCase for route parameter names: router.get('/user-profile/:userId', handler).⁵ FastAPI follows the same split: route segments are kebab-case, Python function parameter names are snake_case.⁶ Converting a URL path to path/case first, then splitting the segments for use in route and parameter naming, keeps the two formats visually separate.

Mapping path/case URL segments to Python function names in FastAPI

A FastAPI route like @app.get("/order-line-item/{order_id}") has a kebab-case path segment and a snake_case path parameter. When you design a new endpoint, paste the resource name into this converter to get the path/case URL structure, then convert the individual segments to snake_case for parameter names. "orderLineItem" becomes "order/line/item" as the path structure. CapyToolkit converts each line independently, so converting a full list of REST resources to their URL path segments takes one paste.

When to use this

Use this when generating URL path segments from module names, creating Go import paths from package identifiers, or converting category hierarchies to filesystem directory paths.

Examples

UserAuthentication
PaymentGateway
OrderManagement

user/authentication
payment/gateway
order/management

Audio Tools
Text Utilities
Network Analysis

audio/tools
text/utilities
network/analysis