Conversor gratuito de CSS a JavaScript

Cómo usar

Esta herramienta analiza las propiedades CSS y las convierte a sintaxis de objeto JavaScript. Los nombres de propiedades en kebab-case (como background-color) se convierten automáticamente a camelCase (backgroundColor). Los valores CSS se preservan tal cual. Puedes introducir propiedades individuales o una regla CSS completa con selectores.

El movimiento CSS-in-JS, brevemente

¿Por qué existe este problema de conversión? Porque en 2014 una generación de desarrolladores frontend decidió que CSS en hojas de estilo separadas había fallado a escala. El momento fundacional fue la charla de Christopher «Vjeux» Chedeau «CSS in JS» en NationJS el 15 de noviembre de 2014: un ingeniero de Facebook argumentando que la cascada global de CSS, la falta de seguimiento de dependencias y la acumulación de código muerto lo convertían en la peor parte de las grandes web apps. La charla encendió un movimiento. JSS (Oleg Slobodskoi) salió a finales de 2014 como la primera biblioteca CSS-in-JS de propósito general. CSS Modules llegó en 2015 como un enfoque al scoping en tiempo de build. styled-components (Glen Maddern + Max Stoiber) salió en octubre de 2016, popularizando la API de tagged-template-literal donde escribes CSS dentro de backticks adjuntos a una definición de componente. Emotion (Kye Hohenberger) salió el 10 de julio de 2017 con tanto la API estilo styled-components como un prop css más flexible que tomaba objetos JavaScript directamente, exactamente el formato que esta herramienta produce. Stitches (Modulz/Pedro Duarte) salió en 2020 con una API basada en variantes pero quedó sin mantener a mediados de 2023 y fue archivado formalmente en abril de 2026.

El péndulo ha vuelto a oscilar. El artículo de Sam Magura «Why We're Breaking Up with CSS-in-JS» el 16 de octubre de 2022 (escrito por un mantenedor de Emotion) fue el punto de inflexión. El argumento técnico: CSS-in-JS en runtime ralentiza mensurablemente los renders de React (el propio benchmark de Magura sobre el Spot Member Browser bajó la mediana del tiempo de render de 54,3 ms a 27,7 ms tras migrar fuera de Emotion, aproximadamente 2× más rápido); los tamaños de bundle son más grandes; los costes de serialización se acumulan. El argumento arquitectónico: React Server Components (estabilizados por Next.js 13.4 el 4 de mayo de 2023) no pueden usar React Context, del que la mayoría de bibliotecas CSS-in-JS dependen para theming. La oleada de reemplazo: Tailwind CSS (Adam Wathan, con el lanzamiento v4 el 22 de enero de 2025); Vanilla Extract (Mark Dalgleish en Seek, 26 de marzo de 2021) para CSS-in-TypeScript en build-time; CSS Modules para nombres de clase scoped sin coste de runtime; y la cohorte compile-a-estático superviviente nombrada en el propio post de Magura: vanilla-extract, Linaria, Compiled, StyleX y Pigment CSS. JSS mismo fue deprecated el 14 de mayo de 2024; styled-components pasó a modo mantenimiento el 17 de marzo de 2025. CSS-in-JS en runtime ya no es el por defecto para nuevos proyectos React en 2026, pero una codebase gigantesca de styled-components y Emotion existentes persiste, y convertir CSS a la forma objeto de esas bibliotecas sigue siendo la realidad diaria para muchos equipos.

Las superficies de API de las bibliotecas principales

El inline style de React (el prop style) es la baseline universal, cada componente React acepta un objeto style cuyas claves son propiedades CSS en camelCase. Sin soporte para pseudo-clases (:hover), media queries o !important; esto es «inline style» en el sentido del antiguo atributo HTML style="...", solo que con un objeto JavaScript en lugar de una cadena. La salida de esta herramienta cae directamente en style={...}. styled-components toma tagged template literals que contienen cadenas CSS reales: const Button = styled.div`background: red; padding: 10px;`. El CSS es CSS real, kebab-case y todo, generalmente no necesitas este convertidor para styled-components a menos que estés migrando de inline styles a un componente styled. Emotion soporta ambas APIs: la API styled (template literals como styled-components) y el prop css con un objeto JavaScript (camelCase, exactamente el formato que esta herramienta produce). Para el prop css de Emotion, la salida de este convertidor es directamente usable. JSS usa un formato objeto similar con algunas características adicionales (theming, nombres de clase generados automáticamente) pero la sintaxis de propiedad camelCase básica es la misma. El binding de style de Vue (:style="...") acepta la misma sintaxis de objeto camelCase que el inline style de React. Vanilla Extract usa una forma objeto tipada más estricta con funciones wrapper style({ ... }) explícitas; el objeto camelCase interno tiene la misma forma.

Casos límite y trampas

• La excepción del prefijo de proveedor ms. La mayoría de prefijos de proveedor ponen mayúscula tras camelCase: -webkit-transform → WebkitTransform, -moz-appearance → MozAppearance, -o-transition → OTransition. Pero el prefijo de Microsoft es la excepción: -ms-flex → msFlex con m minúscula, porque así es como la fuente de React DOM lo define. Esta es la trampa CSS-to-JS más googleada.
• Propiedades sin unidades. React DOM mantiene una lista de propiedades donde los números desnudos son válidos (z-index, opacity, line-height, flex-grow, flex-shrink, order, columns y varias otras). Para estas, zIndex: 5 está bien. Para todo lo demás, los valores dimensionales necesitan unidades como cadenas: width: '100px', no width: 100 (que React tratará como '100px' por defecto silencioso, conveniente pero lossy si querías % o vh).
• calc(), var() y propiedades personalizadas CSS. Estas funcionan como valores cadena: width: 'calc(100% - 20px)', color: 'var(--brand-color)'. Las propiedades personalizadas (variables CSS) necesitan comillas alrededor del --name: '--my-var': 'red'.
• !important no funciona en los inline styles de React. El prop style de React ignora silenciosamente las anotaciones !important. Si necesitas sobrescribir una regla de mayor especificidad, usa una hoja de estilo real (CSS Modules, Tailwind, styled-components), los inline styles no son la herramienta correcta.
• Contenido cadena vacía. content: '' requiere quoting cuidadoso en JavaScript: content: "''": un valor cadena vacía, pero el valor en sí es un literal cadena vacía CSS que necesita que los apóstrofes circundantes se preserven.
• Reglas anidadas y pseudo-selectores. La conversión CSS-to-JS plana produce un objeto plano, estados hover, media queries y estilos de pseudo-elemento necesitan la propia estructura de la biblioteca de destino. El prop css de Emotion soporta objetos anidados ('&:hover': { background: 'red' }); el inline style de React no.
• Propiedades abreviadas. margin: 10px 20px 10px 20px permanece como cadena en forma JS: margin: '10px 20px 10px 20px'. React permite la abreviatura; algunas bibliotecas CSS-in-JS advierten que puede interactuar de forma inesperada con variantes longhand.

Casos de uso comunes

• Inline styles React. Convertir snippets CSS de un diseñador o hoja de estilo al formato objeto style={...} para componentes que no tienen una hoja de estilo asociada.
• Prop css de Emotion. Migrar de un archivo CSS separado al prop css de sintaxis-objeto de Emotion, donde camelCase + forma JS-objeto es la entrada nativa.
• Animaciones JavaScript. GSAP, anime.js, Motion One y Framer Motion todos aceptan objetos style como objetivos de keyframes. El formato camelCase también es requerido allí.
• Tokens de design system. Convertir valores de propiedad personalizada CSS en constantes JavaScript para usar en sistemas de design-token (Style Dictionary, Theo, etc.) donde TypeScript o JS es la fuente canónica de verdad.
• Migración JSS. Material UI v4 y anteriores usaban JSS pesadamente; convertir prototipos CSS a forma objeto JSS es el punto de fricción. Nota que Material UI v5+ se movió a Emotion por defecto; este es más bien un caso de uso legacy.
• Binding de style inline Vue. :style="{...}" en plantillas Vue usa el mismo formato objeto camelCase que el prop style de React; la salida de este convertidor es directamente usable en plantillas Vue también.

Alcance honesto: lo que esta herramienta hace y no hace

Esta herramienta convierte declaraciones CSS a sintaxis de objeto JavaScript con claves camelCase y valores cadena correctamente entrecomillados. Maneja las reglas de mayúsculas de prefijos de proveedor (incluida la excepción minúscula ms). No traduce a la API de una biblioteca específica más allá de producir el objeto camelCase, aún tienes que saber si tu codebase quiere el objeto dentro de styled.div`...`, dentro de una llamada css de Emotion, dentro de un prop style de React, o dentro de un binding :style de Vue. La elección depende de tu biblioteca, no del convertidor. La herramienta tampoco maneja reglas anidadas y pseudo-selectores automáticamente, la sintaxis de objeto anidado de Emotion ('&:hover': {...}) y la anidación de template-literal de styled-components funcionan diferente y necesitan estructuración manual. Para una migración completa de un archivo CSS a una biblioteca CSS-in-JS, espera hacer alguna reestructuración más allá de la conversión propiedad-por-propiedad que esta herramienta proporciona.

Privacidad: por qué el solo-navegador importa aquí

El CSS rara vez contiene secretos, pero las hojas de estilo propietarias revelan información sobre la taxonomía interna de clases de un sitio, sus tokens de design system, y a veces su hipótesis de prueba A/B a través de selectores específicos del experimento. Las herramientas de conversión del lado del servidor requieren subir el CSS, que se queda en sus logs. Para estilos de producto internos, archivos source-of-truth de design system, o branding en progreso, la conversión solo-navegador lo mantiene local. Esta herramienta ejecuta toda la transformación en tu navegador, verifica en la pestaña Network de DevTools mientras haces clic en Convertir, o pon la página offline (modo avión) y el convertidor sigue funcionando.

Preguntas frecuentes

¿Cómo se convierten las propiedades CSS a camelCase?

Cada guion en una propiedad CSS kebab-case se elimina y la siguiente letra se pone en mayúscula: background-color → backgroundColor, border-radius → borderRadius, margin-top → marginTop. Las propiedades con prefijo de proveedor siguen la misma regla con mayúsculas: -webkit-transform → WebkitTransform (W mayúscula), -moz-appearance → MozAppearance. La famosa excepción es el prefijo Microsoft: -ms-flex → msFlex con m minúscula, porque así es como React DOM lo define.

¿Funciona esto para media queries y pseudo-clases?

Los objetos style JavaScript planos (el prop style de React, :style de Vue) no soportan media queries o pseudo-clases, esos son conceptos de hoja de estilo. Las bibliotecas CSS-in-JS que aceptan sintaxis objeto (prop css de Emotion, JSS) las soportan a través de objetos anidados: '&:hover': { background: 'red' }, '@media (min-width: 768px)': { padding: '20px' }. La documentación de la biblioteca de destino mostrará la estructura de anidación exacta. Esta herramienta produce el objeto plano; lo envuelves en la sintaxis de anidación de la biblioteca manualmente.

¿Por qué !important no funciona en los inline styles de React?

El prop style de React ignora silenciosamente las anotaciones !important: no son parte de la gramática de literal objeto JS y el renderer de React no las traduce. Si necesitas sobrescribir una regla de mayor especificidad, usa una hoja de estilo real (CSS Modules, Tailwind, styled-components, CSS plano). El mecanismo de inline-style de React es para estilos puntuales o dinámicos donde la especificidad no es una preocupación; !important pertenece a una hoja de estilo.

¿Debería seguir usando CSS-in-JS en 2026?

Para nuevos proyectos React, el por defecto actual es «no, usa Tailwind, CSS Modules, o Vanilla Extract.» El artículo de Sam Magura de octubre de 2022 desde dentro del equipo Emotion (combinado con la incompatibilidad de Context de React Server Components) empujó al ecosistema hacia soluciones build-time-only. styled-components pasó a modo mantenimiento el 17 de marzo de 2025; JSS fue deprecated el 14 de mayo de 2024. Para codebases existentes con inversión significativa en styled-components o Emotion, sin prisa por migrar, ambas bibliotecas siguen funcionando, y el coste de runtime es el tipo de cosa que optimizas cuando aparece en el profiling. Para un proyecto completamente nuevo en 2026: Tailwind v4 (lanzado el 22 de enero de 2025) es la elección más popular; Vanilla Extract para proyectos que quieren typing TypeScript estricto en estilos; CSS Modules para proyectos que quieren abstracción mínima.

¿Puedo convertir tokens de design-system de esta forma?

Para un snippet puntual, sí. Para un design system entero (típicamente docenas o cientos de tokens organizados por color, espaciado, tipografía, movimiento) usa una herramienta dedicada como Style Dictionary o Theo, ambas toman una única fuente de verdad (JSON, YAML, o JS) y producen a múltiples destinos (propiedades personalizadas CSS, constantes JS, iOS Asset Catalogs, Android XML, etc.). La ventaja de una herramienta de design-token real es la consistencia entre plataformas; este convertidor es para el caso donde tienes un snippet CSS en mano y quieres la forma JS ahora mismo.

¿Mi CSS se envía a algún sitio?

No. La conversión se ejecuta enteramente en tu navegador vía JavaScript. El CSS que pegas nunca cruza la red, verifica en la pestaña Network de DevTools mientras haces clic en Convertir, o pon la página offline tras cargar y confirma que la herramienta sigue funcionando. Seguro para hojas de estilo propietarias, archivos source-of-truth de design system, o cualquier CSS que revele taxonomías internas de clases que no querrías ver copiadas en el disco duro de un desconocido.

Herramientas relacionadas