← Blog · 30 de abril de 2026 · Equipo de ConvertCaseHQ · 7 min de lectura

camelCase y PascalCase: ¿en qué se diferencian?

La única diferencia entre camelCase y PascalCase es la primera letra. camelCase empieza en minúscula y pone en mayúscula cada una de las palabras siguientes (userName, parseResponse). PascalCase pone en mayúscula todas las palabras, incluida la primera (UserName, ResponseParser). Por convención, PascalCase marca los tipos (clases, interfaces, enums, componentes de React) y camelCase marca los valores y las acciones (variables, funciones, métodos, propiedades).

Esa única mayúscula transmite más información de lo que parece. A continuación verás qué indica, en qué lenguajes es obligatoria y no una simple cortesía, y la parte en la que nadie se pone de acuerdo: las siglas.

camelCase y PascalCase de un vistazo

Ojo con el vocabulario cuando leas guías de estilo. Mucha gente dice «camel case» para los dos estilos, y PEP 8 incluso menciona CamelCase como otro nombre de CapWords, su término para PascalCase. Si no está claro a qué se refiere una guía, mira sus ejemplos.

Por qué importa la primera letra: tipos frente a valores

La convención te permite leer código sin tener que consultar nada. En const invoice = new Invoice(order) ves de un vistazo que Invoice es lo que construyes, y invoice, lo que obtienes. Las firmas de TypeScript funcionan igual: en function total(order: Order): Money, el nombre en minúscula es el valor y los nombres con mayúscula son tipos.

También permite que una misma palabra nombre un tipo y un valor sin que choquen, algo que pasa constantemente: user: User, config: Config, request: Request. En un lenguaje que distingue mayúsculas y minúsculas son identificadores distintos, y la mayúscula le dice al lector cuál es cuál.

Dónde lo impone el lenguaje

En JavaScript, Java, C# y Python, la mayúscula inicial en el nombre de una clase es solo una convención. Nada te impide escribir class invoice. En JavaScript puedes convertir la convención en una comprobación con la regla new-cap de ESLint: por defecto marca new invoice(), y también marca la llamada sin new a una función con mayúscula, como Invoice(), que suele ser un error. Algunos lenguajes y frameworks van más allá y llevan la regla incorporada.

Go: la primera letra es la regla de visibilidad

Go no tiene palabras clave public ni private. Un nombre a nivel de paquete, un campo de un struct o un método se exporta si su primera letra es mayúscula, y es privado de su paquete si es minúscula. Elegir entre PascalCase y camelCase es la forma de decidirlo.

package shapes

import "math"

// Circle is exported, so other packages can use it.
type Circle struct {
	Radius float64 // exported field
	label  string  // unexported field
}

// Area is exported.
func Area(c Circle) float64 { return math.Pi * square(c.Radius) }

// square is unexported: only code inside package shapes can call it.
func square(x float64) float64 { return x * x }

c := shapes.Circle{Radius: 2}
fmt.Println(shapes.Area(c))   // fine
fmt.Println(shapes.square(2)) // compile error: square is not exported

Por eso Effective Go dice también que el getter de un campo no exportado owner debe llamarse Owner, no GetOwner. La mayúscula ya te indica que es la vía de acceso pública.

React: los componentes deben empezar por mayúscula

La documentación de React lo dice sin rodeos: los nombres de los componentes deben empezar por mayúscula o no funcionarán. JSX trata una etiqueta en minúscula, como <section>, como un elemento HTML, y una con mayúscula, como <OrderSummary />, como tu componente.

Ruby: los nombres de clase son constantes

En Ruby, cualquier nombre que empiece por mayúscula es una constante, y los nombres de clase tienen que ser constantes. class Invoice funciona; class invoice es un error de sintaxis («class/module name must be CONSTANT»).

Cuál usar en cada lenguaje

• JavaScript y TypeScript: camelCase para variables, funciones, métodos y propiedades; PascalCase para clases, interfaces, alias de tipo, enums y componentes.
• Java y Kotlin: el mismo reparto, más mayúsculas con guiones bajos para las constantes de verdad (MAX_RETRIES).
• C#: PascalCase es mucho más frecuente que en otros lenguajes. Los métodos, las propiedades, los eventos, los campos públicos, los espacios de nombres e incluso las constantes van en PascalCase; camelCase queda para los parámetros y las variables locales, con _camelCase para los campos privados. Una firma típica es public decimal CalculateTotal(decimal taxRate).
• Swift: PascalCase para tipos y protocolos, camelCase para todo lo demás.
• Go: el que corresponda a la visibilidad que quieras.
• Python: PascalCase solo para las clases. Las funciones y las variables van en snake_case, y PEP 8 solo admite camelCase donde ya es el estilo predominante en código antiguo.
• PHP (PSR-1): clases en PascalCase, métodos en camelCase.

Para las constantes, los archivos y lo demás, consulta nuestra guía rápida de estilos de nomenclatura para desarrolladores.

La parte difícil: siglas y acrónimos

¿Es userId o userID? ¿HttpClient o HTTPClient? Las principales guías de estilo dan respuestas distintas:

Nuestra opinión: si la guía de tu lenguaje tiene una regla, síguela, porque es lo que esperan la biblioteca estándar y tus compañeros. Si no la tiene, trata las siglas como palabras (HttpClient, userId). Así se siguen viendo los límites entre palabras cuando se juntan dos siglas (compara XMLHTTPRequest con XmlHttpRequest), y los nombres sobreviven a la conversión automática entre estilos. Incluso el propio XMLHttpRequest del navegador mezcla los dos enfoques en un solo nombre.

Si quieres más contexto, las convenciones de uso de mayúsculas de Microsoft son un buen ejemplo de un conjunto completo de reglas recogido en una sola página.

Convertir entre camelCase y PascalCase

Con un nombre sencillo, la conversión afecta a un solo carácter: cambia la primera letra de minúscula a mayúscula o al revés.

const toPascal = (s) => s.charAt(0).toUpperCase() + s.slice(1);
const toCamel = (s) => s.charAt(0).toLowerCase() + s.slice(1);

toPascal("orderTotal"); // "OrderTotal"
toCamel("OrderTotal");  // "orderTotal"
toCamel("HTMLParser");  // "hTMLParser" (acronyms need a smarter split)

Esa última línea es la razón por la que las herramientas dividen primero los nombres en palabras. Esto es lo que produce el conversor de mayúsculas y minúsculas de ConvertCaseHQ con algunas entradas difíciles:

Divide por las mayúsculas que ya existen y escribe las siglas como palabras, lo que coincide con la regla de Google. Si tu proyecto sigue las reglas de siglas de Go, de .NET o de PEP 8, corrige esos nombres a mano después (getUserId pasa a ser getUserID en Go). Los nombres de marca son la otra trampa: ningún algoritmo sabe que IPhone queda mal.

Dos despistes fáciles de evitar

El primero es poner en mayúscula una instancia: const Cart = new ShoppingCart() hace que Cart parezca una segunda clase, y el siguiente que lea el código irá a buscar su definición. El segundo es una función auxiliar en PascalCase en JavaScript, como function FormatPrice(). Salvo que sea un constructor o un componente de React, quien la lea supondrá que necesita new o JSX, y new-cap se quejará cuando la llames sin ninguno de los dos.

Una regla práctica

Si es un tipo, o algo que construyes con new, usa PascalCase. Si es un valor o una acción, usa camelCase. Deja que la guía de tu lenguaje decida lo de las siglas, y que un linter se acuerde del resto. Para los detalles de JavaScript, incluidas las constantes y los campos privados, consulta nuestra guía de nombres en JavaScript.