Convert snake_case to PascalCase

snake_case to PascalCase Converter

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