Convert camelCase to PascalCase

camelCase to PascalCase Converter

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. 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.

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