Convert Anything to PascalCase

PascalCase Converter,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" produce "2ndAttempt", which is not standard PascalCase but preserves the original form since no valid transformation exists for digit-prefixed identifiers.

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