PascalCase

Capitalize the first letter of every word, no separators. Also known as UpperCamelCase.

Where it's used

Class names in most languages, .NET, React components, Go (exported names).

Worked examples

The engine handles every common input pattern — spaces, hyphens, underscores, camelCase humps, and ALLCAPS acronym runs — and produces the canonical PascalCase output.

Input PascalCase
user profile UserProfile
http client HttpClient
XML parser XmlParser
create new user CreateNewUser

Smart tokenization

Our engine splits identifiers correctly. HTMLParser doesn't become h_t_m_l_parser — the ALLCAPS run is recognized as a single token and produces html_parser. getXMLHttpRequest tokenizes to get, XML, Http, Request for clean output in any case format.

What PascalCase means

PascalCase capitalizes the first letter of every word, with no separators between them. The name comes from the Pascal programming language, which used the convention extensively in the 1970s. Today it's the default convention for type names — classes, interfaces, structs, enums — in virtually every C-family and JVM language, regardless of what the language uses for variables or methods.

PascalCase is also called UpperCamelCase when contrasted with regular camelCase. The two conventions are nearly identical; the only difference is whether the first letter is capitalized. This single-character distinction carries enormous semantic weight in many languages.

Where PascalCase is required or canonical

  • Class names in C#, Java, Swift, Kotlin, Python, TypeScript, Rust, and most modern languages. UserAccount, HttpClient, JsonParser.
  • React components: JSX uses the first character's case to distinguish components from HTML elements. <Button /> renders a custom component; <button /> renders the HTML tag.
  • .NET (C# and F#): the Microsoft framework design guidelines mandate PascalCase for all public members — methods, properties, events — not just types. This is one of the major stylistic differences between .NET code and Java/JavaScript code.
  • Go exported identifiers: Go uses the case of the first character as the visibility modifier. PascalCase names are exported (public); camelCase names are unexported (package-private). This is unusual — most languages use keywords like public or private for visibility — but it makes Go code unambiguous about what's part of a package's API.
  • TypeScript interfaces and types: the same convention as classes, by convention if not by rule.

The case of acronyms

The trickiest decision in PascalCase is what to do with acronyms longer than two letters. There are two competing conventions:

  • Microsoft .NET convention: capitalize only the first letter of acronyms three letters or longer. HtmlParser, JsonClient, XmlReader. Two-letter acronyms are uppercased: IOStream, UIElement.
  • Java/older convention: uppercase entire acronyms. HTMLParser, JSONClient, XMLReader.

The .NET approach is more consistent and produces better tokenization downstream. The Java approach matches how acronyms are written in English prose. Neither is "correct" — pick one and apply it throughout a codebase. Mixed acronym styling within one project is the worst outcome.

Our converter follows the .NET convention by default because it produces cleaner output when tokens are later re-extracted (for instance, when converting back to kebab-case or snake_case for a different context).

Common conversion mistakes

  • Forgetting the first letter: "PascalCase" without capitalizing the leading character isn't PascalCase, it's camelCase. The two are distinct and substituting one for the other in a typed language causes compilation errors.
  • Preserving separators: User_Account isn't PascalCase, it's title-cased snake. PascalCase removes all separators.
  • Mishandling numbers: html5Parser versus Html5Parser versus HTML5Parser — for PascalCase, Html5Parser is the cleanest choice. Numbers don't capitalize the following character.
  • Awkward two-letter words: IO, UI, OS are typically kept uppercase as acronyms even under the "capitalize only first letter" convention. UiElement looks wrong to most developers; UIElement is more conventional.

PascalCase in REST APIs and JSON

Most modern JSON APIs use camelCase or snake_case for property names, not PascalCase. But .NET APIs sometimes serialize objects with PascalCase property names (matching the C# convention), which causes friction with JavaScript clients that expect camelCase. Use a JSON serializer with a configurable naming policy to bridge the gap — both Newtonsoft.Json and System.Text.Json support automatic case conversion during serialization.

For database integration, PascalCase column names work but require quoting in most SQL dialects (since SQL is traditionally case-insensitive and folds identifiers to lowercase or uppercase). It's usually simpler to use snake_case in the database and convert to PascalCase in the application layer.

Convert to PascalCase now.

Open the converter →

See all programming naming conventions.