PascalCase is a naming convention where every word in a compound identifier begins with an uppercase letter — including the very first word. There are no spaces, underscores, or hyphens. Word boundaries are marked purely by capitalization.

The name comes from the Pascal programming language, which popularized this style in the 1970s and 1980s. It is also called UpperCamelCase because it follows the same 'capitalize word starts' rule as camelCase, but without the lowercase first letter.

• ▸UserProfile
• ▸HttpRequestHandler
• ▸GetUserById
• ▸NavigationMenu
• ▸DatabaseConnectionString
• ▸ButtonClickHandler

Every word — no exceptions — starts with an uppercase letter. This is what distinguishes it from camelCase, where only words after the first are capitalized.

Class names across almost every language: In JavaScript, TypeScript, Java, Python, C#, Swift, Kotlin, Rust, and Go, class names use PascalCase. This is one of the most universal conventions in all of software development — UserService, DatabaseConnection, EventEmitter, HttpClient are idiomatic in all of these languages.

React components: React uses the capitalization of a component name to determine how to process it at runtime. A component starting with a lowercase letter is treated as an HTML tag — <usercard /> searches for a native DOM element called 'usercard', finds nothing, and renders nothing. <UserCard /> tells React this is a custom component and renders your code. PascalCase is a functional requirement for React components, not just a style preference.

TypeScript interfaces and type aliases: TypeScript's own codebase and every major style guide specifies PascalCase for interface and type names — interface UserProfile, type ApiResponse, type ButtonVariant. This separates type-level identifiers from value-level identifiers visually.

Go exported identifiers: Go uses PascalCase to encode visibility. Any function, variable, struct, or method starting with an uppercase letter is exported (public). Any identifier starting with a lowercase letter is unexported (package-private). Writing PascalCase in Go is not just convention — it is the mechanism that controls the public API surface of a package.

C# public members: Microsoft's official C# guidelines apply PascalCase to virtually everything public — class names, method names, properties, events, and namespaces. C# goes further than most languages: even public constants use PascalCase (MaxRetries, DefaultTimeout), unlike Java or Python which use CONSTANT_CASE.

PascalCase and camelCase look almost identical. The only difference is the first letter: camelCase starts lowercase, PascalCase starts uppercase.

camelCase: getUserById, handleClick, isAuthenticated

PascalCase: GetUserById, HandleClick, IsAuthenticated

In most languages, this single-letter difference carries significant semantic weight. camelCase signals a value or behavior — a variable, a function, an instance method. PascalCase signals a blueprint or type — a class, an interface, a component, a constructor.

When you read code written by an experienced developer, you can instantly tell which identifiers are 'things' and which are 'kinds of things' — not because of comments or documentation, but because camelCase and PascalCase visually separate the two categories at a glance.

A common inconsistency in PascalCase involves acronyms. Should it be HttpClient or HTTPClient? XmlParser or XMLParser? UserId or UserID?

Different style guides handle this differently. Microsoft's .NET guidelines now recommend treating acronyms as regular words — HttpClient, XmlParser, UserId — capitalizing only the first letter and lowercasing the rest. This produces more readable identifiers when acronyms are embedded mid-word: XmlHttpRequest is easier to read than XMLHTTPRequest.

Google's Java style guide takes the same approach: treat acronyms as words. XmlParser, not XMLParser. HttpRequest, not HTTPRequest.

The Go community follows a different standard: acronyms should be all-caps — ServeHTTP not ServeHttp, parseJSON not parseJson. Go's linter enforces this.

The practical advice: follow whichever convention your language's official style guide specifies, and be consistent within your codebase. Mixing XMLParser and HttpClient in the same project creates unnecessary noise.

Of all the contexts where PascalCase is used, React makes it the most consequential. React distinguishes between HTML elements and custom components purely through the first letter of the JSX tag name — which means getting PascalCase wrong produces a silent failure, not an error.

• ▸<div> — valid HTML element, renders as a div
• ▸<userCard> — React tries to render an HTML element called 'usercard', finds nothing, renders nothing
• ▸<UserCard> — React recognizes this as a custom component and renders it
• ▸<usercard /> — same problem as <userCard>, just self-closing

This behavior is defined in the JSX specification and React's runtime. It is the reason why every tutorial, style guide, and linting rule for React is absolute on this point: component names must start with an uppercase letter. PascalCase is the natural convention that satisfies this requirement.

Higher-order components, context providers, and render props all follow the same rule — any function that returns JSX and is used as a component must be PascalCase.