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
publicorprivatefor 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_Accountisn't PascalCase, it's title-cased snake. PascalCase removes all separators. - Mishandling numbers:
html5ParserversusHtml5ParserversusHTML5Parser— for PascalCase,Html5Parseris the cleanest choice. Numbers don't capitalize the following character. - Awkward two-letter words:
IO,UI,OSare typically kept uppercase as acronyms even under the "capitalize only first letter" convention.UiElementlooks wrong to most developers;UIElementis 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.