Skip to content

Conversor mayúsculas y minúsculas

Última verificación mayo 2026 — corre en tu navegador

Conversor mayúsculas y minúsculas — Cambiar texto a MAYÚS o minús online

Pega cualquier texto y elige un estilo — MAYÚSCULAS para encabezados gritados, minúsculas para normalizar entrada, Tipo Título para titulares, Tipo Oración para prosa, y luego cuatro estilos de programador para nombrar cosas en código (camelCase, PascalCase, snake_case, kebab-case). Los cuatro estilos de código quitan automáticamente los diacríticos primero usando normalización Unicode NFD, así que "Café Móvil" se vuelve un limpio `cafeMovil` en vez de romperse en "é". El estilo activo se resalta para que puedas comparar A/B unos cuantos antes de decidirte, y un único botón Copiar pone el resultado en tu portapapeles. Útil para nombrar un nuevo fichero/rama/columna de BD, normalizar entrada de usuario de un formulario, generar una clave JSON desde una etiqueta humana o limpiar un encabezado copy-pegado antes de meterlo en un CMS.

Sobre esta herramienta

Tipo Título capitaliza la primera letra de cada palabra separada por espacios y minimiza el resto, lo cual es rápido y suficiente para la mayoría de titulares (NO aplica las reglas de manual de estilo inglés "no capitalices palabras cortas" — esa es otra herramienta). Tipo Oración minimiza todo y luego re-capitaliza tras `.`, `!`, `?` seguidos de espacio, así que entrada multi-oración recupera la primera letra de cada oración. Los cuatro estilos de programador empiezan normalizando NFD la entrada y quitando las marcas combinantes resultantes (`U+0300`-`U+036F`), luego colapsan los no-alfanuméricos: camelCase capitaliza cada carácter de frontera de palabra y minimiza el primero del todo; PascalCase es camelCase con el primer carácter también capitalizado; snake_case une fronteras de palabra minimizadas con `_`; kebab-case es snake_case con `-` en vez de `_`. Las rutas snake/kebab también dividen en transiciones minúscula-a-mayúscula dentro de la entrada, así que un `myCamelCase` existente se vuelve `my_camel_case` correctamente en vez de `mycamelcase`. Todas las transformaciones son operaciones puras de string JavaScript — sin subida, sin API. Casos de uso: nombrar una nueva rama git, generar una columna de BD desde una etiqueta, construir una clase CSS desde un encabezado de sección, preparar un slug desde un título o normalizar una fila de encabezados CSV.

  • 8 estilos: MAYÚSCULAS, minúsculas, Título, Oración, camelCase, PascalCase, snake_case, kebab-case
  • Los estilos de programador quitan diacríticos vía normalización NFD
  • snake/kebab dividen en transiciones minúscula→mayúscula (miFoo → mi_foo)
  • Tipo Oración re-capitaliza tras . ! ? + espacio
  • Tipo Título capitaliza cada palabra separada por espacios
  • Cambio entre estilos con un clic, estilo activo resaltado
  • Copia el resultado al portapapeles con toast de confirmación
  • Reactivo — la salida se actualiza al instante al cambiar de estilo
  • Transformaciones de string puras en cliente, sin llamada API
  • Útil para nombres de rama, columnas de BD, clases CSS, slugs, encabezados CSV

Gratis. Sin registro. Tus datos permanecen en tu navegador. Anuncios mediante Google AdSense (con consentimiento).

Preguntas frecuentes

¿Por qué la normalización NFD elimina diacríticos de 'café' pero no de emoji o caracteres CJK?

NFD (Descomposición Canónica, definida en UAX #15 — Whistler ed., revisión 57 ligada a Unicode 17.0) divide los caracteres precompuestos en una letra base más una marca combinante — así 'é' (U+00E9) se descompone en 'e' (U+0065) + acento agudo combinante (U+0301). La marca combinante está en el bloque Combining Diacritical Marks (U+0300–U+036F), y una regex de strip después del normalize la elimina limpiamente. Los emoji como 😀 (U+1F600) y los ideogramas CJK como 漢 (U+6F22) son atómicos — no tienen descomposición canónica en base + marca combinante, así que NFD los deja como un único code point y la regex de diacríticos no los toca. Los cuatro estilos de programador (camelCase, PascalCase, snake_case, kebab-case) eliminan después todo lo que esté fuera de letras ASCII y dígitos, que es cuando los emoji y CJK se descartan — pero eso es el filtro alfanumérico, no la pasada NFD.

¿Por qué snake_case convierte 'myCamelCase' en 'my_camel_case' y no en 'mycamelcase'?

Los caminos snake_case y kebab-case dividen por transiciones de minúscula a mayúscula dentro de la entrada antes de unir con el separador. La regex inserta un límite donde sea que una letra minúscula o dígito esté inmediatamente seguida por una letra mayúscula, así que 'myCamelCase' se convierte internamente en 'my Camel Case', luego pasa a minúsculas como 'my camel case', y luego se une con '_'. Esta es la convención estándar compartida por la mayoría de bibliotecas snake_case (`underscore` de Ruby, `inflection` de Python, `_.snakeCase` de Lodash) — preserva los límites de palabra que un identificador camelCase existente ya codifica, en lugar de colapsarlos. La misma lógica produce 'parse_html_file' a partir de 'parseHTMLFile' — las secuencias de mayúsculas consecutivas se tratan como un único límite de palabra, y todo el resultado pasa a minúsculas según la convención snake_case.

¿Sigue Title Case las reglas de los manuales de estilo en inglés sobre palabras cortas?

No — esta implementación capitaliza la primera letra de cada palabra separada por espacio y pasa el resto a minúsculas, que es el Title Case algorítmico simple. Los manuales de estilo en inglés (AP, Chicago Manual of Style, APA) añaden una regla adicional según la cual los artículos ('a', 'an', 'the'), las conjunciones cortas ('and', 'but', 'or') y las preposiciones cortas ('in', 'on', 'of') se mantienen en minúscula a menos que sean la primera o última palabra — así que una versión estricta-AP de 'A Tale of Two Cities' es 'A Tale of Two Cities', no 'A Tale Of Two Cities'. La versión simple es correcta para titulares en sistemas CMS, identificadores de código y la mayoría de uso casual; para texto editorial dirigido a un manual específico, una post-pasada que pase la lista de palabras funcionales a minúsculas cubre esa diferencia.

¿Por qué este conversor no maneja correctamente el plegado de mayúsculas I/i del turco?

String.prototype.toLowerCase / toUpperCase de JavaScript usan los mapeos de mayúsculas por defecto de Unicode. Bajo el mapeo Unicode por defecto, la İ con punto (U+0130) pasa a minúscula como i + punto combinante encima (U+0069 + U+0307) — la marca combinante preserva la información de roundtrip de que el origen tenía una mayúscula con punto — y la I capital sin punto (U+0049) pasa a minúscula como i latina simple (U+0069). El turco tiene una convención diferente: bajo el locale turco, la İ con punto pasa a minúscula como i simple (U+0069) y la I capital sin punto pasa a minúscula como ı sin punto turca (U+0131). Para obtener la convención turca, las aplicaciones llaman a String.prototype.toLocaleLowerCase('tr'), que usa el mapeo consciente del locale coordinado con la resolución de locale de ECMA-402. Esta herramienta usa el mapeo Unicode por defecto porque las convenciones de identificadores específicas del turco son raras en el caso de uso global; para código o nombres de archivo dirigidos a locales turcos, la variante consciente del locale cubre la diferencia. La misma salvedad rige para el azerí (az), que comparte la I con/sin punto del turco.

¿Cómo maneja esta herramienta la accesibilidad para lectores de pantalla?

La región de salida para cada estilo está marcada con aria-live="polite", el patrón del Criterio de Éxito 4.1.3 de WCAG (Mensajes de Estado, introducido en WCAG 2.1, recomendación del W3C del 5 de junio de 2018; trasladado sin cambios a WCAG 2.2, recomendación del 5 de octubre de 2023). Las regiones live polite encolan anuncios tras cualquier habla en progreso, así que cambiar de estilo o editar la entrada anuncia el resultado sin interrumpir al usuario a mitad de frase. Los lectores de pantalla (NVDA, JAWS, VoiceOver) consumen la región live automáticamente; el usuario no necesita hacer nada más.

Fuentes (5)
  • Whistler, K. (Ed.) (2025). UAX #15: Unicode Normalization Forms. Unicode Standard Annex, Revision 57 (Unicode 17.0.0, 30 July 2025).
  • The Unicode Consortium (2024). The Unicode Standard, Version 16.0 — UCD CaseFolding.txt (simple vs full case folding). Unicode Consortium, Mountain View, CA.
  • ECMA International (2025). ECMAScript 2025 Language Specification — String.prototype.toLowerCase / toUpperCase / normalize. ECMA-262, 16th edition, June 2025.
  • ECMA International (2025). ECMAScript 2025 Internationalization API Specification — locale-aware case behavior (Turkish I/ı, dotted/dotless). ECMA-402, 12th edition, June 2025.
  • World Wide Web Consortium (W3C) (2018). Web Content Accessibility Guidelines (WCAG) 2.1 — Success Criterion 4.1.3 Status Messages. W3C Recommendation 5 June 2018; carried unchanged into WCAG 2.2 (Recommendation 5 October 2023).

Son las publicaciones originales en las que se basan las fórmulas de esta herramienta. Localízalas con el nombre de la revista y el año en Google Scholar o PubMed.

Por ·