MJML vs HTML tradicional para emails: ventajas y limitaciones

Crear un email responsive parece sencillo hasta que intentas que se vea bien en Gmail, Outlook, Apple Mail, Yahoo, clientes móviles y aplicaciones de escritorio al mismo tiempo. En una página web, normalmente trabajamos con HTML, CSS moderno, media queries, Flexbox, Grid y un ecosistema de navegadores bastante predecible. En email, en cambio, entramos en un terreno mucho más delicado.

El desarrollo de emails tiene sus propias reglas. Muchas propiedades CSS no funcionan igual en todos los clientes de correo, algunos estilos deben ir inline, las tablas siguen siendo habituales y Outlook continúa siendo uno de los grandes retos para cualquier persona que maqueta newsletters o emails transaccionales.

Por eso, cuando hablamos de html email responsive, suele aparecer una comparación muy habitual: MJML vs HTML tradicional. ¿Conviene escribir todo el email a mano usando HTML y CSS? ¿O es mejor apoyarse en MJML para generar un código más compatible y fácil de mantener?

La respuesta no es absoluta. MJML puede ser una herramienta muy útil para crear emails responsive de forma más rápida, limpia y ordenada. Pero el HTML tradicional sigue teniendo sentido cuando necesitas un control muy preciso sobre el resultado final.

En este artículo vamos a ver qué aporta MJML, qué limitaciones tiene, cuándo conviene usar HTML tradicional y cómo decidir qué opción encaja mejor según el tipo de proyecto.

Qué significa crear un email responsive

Un email responsive es un correo que se adapta correctamente a diferentes tamaños de pantalla y entornos de lectura. Esto incluye escritorio, móvil, tablet, clientes web, aplicaciones nativas y gestores de correo con distintos motores de renderizado.

En desarrollo web, solemos pensar en responsive design de una forma bastante natural. Ajustamos contenedores, usamos unidades relativas, media queries y componentes flexibles. Si vienes del mundo frontend, probablemente ya estés acostumbrada a trabajar con diseños adaptables. De hecho, conceptos como los que se aplican al dibujar con CSS responsive también parten de una idea similar: crear interfaces o composiciones que respondan bien a distintos contextos.

Sin embargo, el email no se comporta como una web normal. Un correo se abre dentro de aplicaciones que pueden modificar, ignorar o interpretar parcialmente el código. Por eso, maquetar emails requiere una mentalidad más conservadora.

Por qué el HTML email responsive es más complejo que una web

El principal problema del email responsive es la fragmentación. Cada cliente de correo tiene sus propias limitaciones. Algunas propiedades CSS funcionan bien en Apple Mail, pero pueden fallar en Outlook. Gmail puede interpretar ciertos estilos de una manera y otro cliente hacerlo de forma distinta.

Esto obliga a trabajar con una base técnica muy específica. En email, todavía es habitual usar estructuras basadas en tablas, estilos inline, anchuras fijas combinadas con comportamiento fluido, condicionales para Outlook, imágenes optimizadas y botones construidos con código compatible.

Aquí no basta con que el email se vea bien en el navegador mientras lo desarrollas. Lo importante es que se vea de forma consistente cuando llega a la bandeja de entrada real.

El error de diseñar emails como si fueran páginas web

Uno de los errores más comunes es intentar trasladar directamente las prácticas del desarrollo web moderno al email. Por ejemplo, usar estructuras con div, CSS externo, Grid, animaciones complejas o técnicas avanzadas puede parecer lógico si vienes del frontend, pero no siempre es recomendable.

Esto no significa que los emails tengan que ser visualmente pobres. Significa que hay que diseñarlos entendiendo sus límites. Igual que en accesibilidad web conviene pensar en la experiencia real de lectura, como comentaba en el artículo sobre la importancia de la accesibilidad web, en email también debemos priorizar claridad, legibilidad y compatibilidad.

Un email efectivo no es el más espectacular técnicamente. Es el que se lee bien, carga rápido, se entiende y permite al usuario actuar sin fricción.

Qué es MJML y por qué facilita la maquetación de emails

MJML, siglas de Mailjet Markup Language, es un lenguaje de marcado pensado específicamente para crear emails responsive. Su objetivo es simplificar la escritura de plantillas de correo sin tener que pelear directamente con todo el HTML basado en tablas.

En lugar de escribir manualmente una estructura compleja de tablas, celdas, atributos y estilos inline, MJML permite trabajar con etiquetas más claras, como mj-section, mj-column, mj-text, mj-image o mj-button.

Si quieres profundizar en la base de esta herramienta, puedes leer también el artículo sobre qué es MJML y por qué facilita la maquetación de emails responsive, donde se explica con más detalle cómo funciona y por qué puede ser tan útil en proyectos de email marketing.

La lógica de MJML

MJML funciona como una capa intermedia. Tú escribes código MJML y la herramienta lo compila a HTML compatible con email.

Un ejemplo muy sencillo sería este:

<mjml>
  <mj-body>
    <mj-section>
      <mj-column>
        <mj-text>
          Hola, este es un email responsive creado con MJML.
        </mj-text>
        <mj-button href="https://example.com">
          Leer más
        </mj-button>
      </mj-column>
    </mj-section>
  </mj-body>
</mjml>

Ese código no es el que recibe directamente el usuario final. MJML lo transforma en HTML preparado para funcionar mejor en distintos clientes de correo.

MJML vs HTML: no son enemigos

La comparación MJML vs HTML tradicional no debería plantearse como si una opción fuera correcta y la otra incorrecta. En realidad, hablamos de dos formas diferentes de afrontar el mismo problema.

El HTML tradicional te da control directo sobre todo el código final. MJML, en cambio, te permite trabajar de forma más declarativa y delegar parte de la complejidad técnica en el compilador.

Dicho de otra manera: MJML reduce el esfuerzo manual, pero también añade una capa de abstracción. Esa capa puede ser una gran ventaja en la mayoría de proyectos, aunque no siempre será la mejor solución si necesitas un control extremo.

Ventajas de MJML frente al HTML tradicional

MJML destaca especialmente cuando necesitas crear emails responsive de forma rápida, ordenada y mantenible. No elimina por completo los problemas del email development, pero sí reduce muchos de los obstáculos habituales.

Código más limpio y fácil de leer

Una plantilla de email escrita en HTML tradicional puede volverse muy larga rápidamente. Las tablas anidadas, los estilos inline y los condicionales para Outlook hacen que el código sea difícil de leer, incluso para personas con experiencia.

Con MJML, el código fuente resulta más claro. Las secciones, columnas, imágenes, textos y botones tienen etiquetas específicas. Esto facilita la lectura y también el mantenimiento.

Por ejemplo, este bloque:

<mj-section>
  <mj-column>
    <mj-text font-size="20px">
      Nueva colección disponible
    </mj-text>
  </mj-column>
</mj-section>

Es mucho más fácil de interpretar que una estructura equivalente en HTML email tradicional.

Desarrollo más rápido

Una de las mayores ventajas de MJML es la velocidad. Permite crear layouts habituales sin escribir desde cero todo el código necesario para que el email se comporte de forma responsive.

Esto resulta especialmente práctico si trabajas con newsletters recurrentes, emails transaccionales o campañas de contenido. Por ejemplo, si estás empezando a diseñar una newsletter, te puede interesar complementar esta comparativa con la guía sobre cómo crear tu primera newsletter responsive con MJML.

En proyectos donde hay que producir emails con frecuencia, ahorrar tiempo en la estructura técnica permite dedicar más atención al contenido, al diseño y a la estrategia.

Mejor punto de partida para emails responsive

MJML está pensado desde el principio para emails responsive. Sus componentes ya están diseñados para adaptarse a diferentes tamaños de pantalla. Esto no significa que todo vaya a funcionar perfecto sin pruebas, pero sí que partes de una base más sólida que escribiendo HTML desde cero sin experiencia en email.

Por ejemplo, las columnas en MJML se apilan automáticamente en móvil en muchos casos. Esto reduce bastante el trabajo manual y evita errores frecuentes en estructuras responsive.

Menos errores repetitivos

Cuando escribes HTML tradicional para emails, es fácil cometer pequeños errores que pueden romper el diseño: una tabla mal cerrada, una anchura inconsistente, un estilo que no se ha puesto inline o una propiedad CSS poco compatible.

MJML ayuda a reducir este tipo de errores porque genera una estructura HTML más preparada para el entorno email. Esto no sustituye las pruebas, pero sí disminuye la probabilidad de fallos básicos.

Mejor mantenimiento de plantillas

En proyectos con varias plantillas, MJML puede mejorar mucho el mantenimiento. Si tienes una newsletter mensual, emails de bienvenida, emails promocionales y mensajes transaccionales, mantener todo en HTML tradicional puede acabar siendo pesado.

Con MJML, el código fuente suele ser más corto y más comprensible. Esto facilita hacer cambios, reutilizar bloques y mantener una línea visual coherente.

MJML y reducción de carga cognitiva

MJML también reduce la carga cognitiva del desarrollo. No tienes que pensar constantemente en cada tabla, cada celda o cada hack de compatibilidad. Puedes centrarte más en la estructura del mensaje y menos en los detalles repetitivos del HTML email.

Esto es importante porque el desarrollo de emails puede volverse muy mecánico y propenso a errores. Una herramienta que simplifique ese proceso puede mejorar tanto la productividad como la calidad final.

Limitaciones de MJML que conviene tener claras

MJML es muy útil, pero no es una solución mágica. Para usarlo bien, también hay que conocer sus limitaciones.

MJML no elimina la necesidad de probar

El hecho de que MJML genere HTML responsive no significa que puedas olvidarte de las pruebas. Los emails deben revisarse en diferentes clientes de correo, dispositivos y tamaños de pantalla.

Esta es una de las ideas más importantes: MJML facilita el trabajo, pero no garantiza compatibilidad absoluta.

Antes de enviar una campaña, conviene comprobar cómo se ve el email en los clientes más relevantes para tu audiencia. En email marketing, una plantilla que funciona bien en tu entorno de desarrollo puede comportarse de forma diferente en la bandeja de entrada real.

Menos control sobre el HTML final

Con MJML no escribes directamente el HTML definitivo. Escribes una sintaxis que después se transforma. Esto hace que el trabajo sea más cómodo, pero puede ser una limitación si necesitas controlar cada detalle del código generado.

Por ejemplo, puede que quieras aplicar un ajuste muy específico para Outlook, modificar una estructura concreta o adaptar el HTML a las exigencias de una plataforma de envío. En esos casos, quizá tengas que revisar el HTML generado o combinar MJML con soluciones personalizadas.

Tiene su propia curva de aprendizaje

Aunque MJML simplifica mucho la maquetación de emails, también requiere aprender su sintaxis. Necesitas familiarizarte con sus componentes, sus atributos y su forma de estructurar los documentos.

Algunas etiquetas habituales son mjml, mj-head, mj-body, mj-section, mj-column, mj-text, mj-image, mj-button, mj-attributes, mj-style y mj-raw.

No es una curva de aprendizaje especialmente difícil, pero existe. Y si ya sabes HTML email tradicional, puede que al principio sientas que estás añadiendo una capa más al flujo de trabajo.

Dependencia del compilador

MJML necesita compilarse a HTML antes de enviar el email. Esto implica añadir un paso al proceso de desarrollo.

Si trabajas con un flujo moderno basado en Node, scripts, control de versiones o herramientas de automatización, esta dependencia no suele ser un problema. Pero si trabajas directamente dentro de un editor visual de email marketing, puede resultar menos cómodo.

Personalizaciones avanzadas más delicadas

MJML funciona muy bien para estructuras frecuentes: cabeceras, bloques de texto, imágenes, botones, columnas y footers. Sin embargo, cuando el diseño se vuelve muy específico, puede que necesites forzar más la herramienta.

Esto puede ocurrir en emails con diseños editoriales complejos, layouts poco convencionales o requisitos muy concretos de marca.

En esos casos, el HTML tradicional puede darte más libertad.

Ventajas del HTML tradicional para emails

Aunque MJML simplifica mucho el trabajo, el HTML tradicional sigue teniendo un papel importante en el desarrollo de emails.

Control total del código

La mayor ventaja del HTML tradicional es el control. Tú decides cada tabla, cada celda, cada atributo, cada estilo inline y cada comentario condicional.

Esto puede ser fundamental en proyectos donde el email debe cumplir requisitos muy estrictos o donde hay que optimizar el resultado para clientes concretos.

No dependes de una herramienta externa

Con HTML tradicional, el código que escribes es el código que se envía, siempre que la plataforma de email no lo modifique. No necesitas compilar ni añadir pasos intermedios.

Esto puede simplificar el flujo si trabajas en entornos muy manuales o si el equipo no quiere incorporar herramientas adicionales.

Mayor flexibilidad para casos especiales

Si tienes experiencia en HTML email, escribir a mano te permite resolver casos muy concretos. Puedes aplicar hacks específicos, ajustar comportamientos para Outlook o adaptar la estructura al sistema de envío que estés usando.

Esta flexibilidad puede ser muy valiosa en proyectos corporativos, plantillas heredadas o emails muy revisados por equipos de diseño, marketing o legal.

Te ayuda a entender mejor el medio

Aprender HTML tradicional para emails te obliga a comprender las reglas reales del entorno. Entiendes por qué se usan tablas, por qué algunos estilos deben ir inline y por qué ciertas propiedades CSS modernas no son seguras.

Incluso si después decides trabajar con MJML, conocer la base del HTML email te ayudará a depurar mejor cualquier problema.

HTML tradicional como conocimiento de fondo

Lo ideal no es usar MJML sin entender nada del HTML que genera. La mejor combinación suele ser esta: usar MJML para ganar velocidad, pero tener conocimientos suficientes de HTML email para revisar, ajustar y corregir cuando sea necesario.

Limitaciones del HTML tradicional frente a MJML

El HTML tradicional ofrece control, pero también tiene costes importantes.

Código más largo y difícil de mantener

Una plantilla responsive escrita a mano puede crecer mucho. Incluso un bloque aparentemente sencillo puede requerir varias tablas, atributos, estilos inline y ajustes específicos.

Esto dificulta el mantenimiento, sobre todo cuando hay varias plantillas o muchas campañas.

Más tiempo de desarrollo

Crear emails responsive con HTML tradicional lleva más tiempo. No solo por escribir el código, sino también por probarlo, corregirlo y adaptarlo.

En equipos donde se producen emails con frecuencia, ese tiempo puede convertirse en un coste importante.

Mayor riesgo de errores

Cuanto más manual es el proceso, más fácil es cometer errores. Una etiqueta mal cerrada o un estilo colocado en el lugar equivocado puede afectar al diseño final.

En este sentido, MJML ayuda a evitar parte del trabajo repetitivo y reduce algunos errores estructurales.

Menor escalabilidad

Si una marca necesita muchas plantillas, variaciones y bloques reutilizables, mantener todo en HTML tradicional puede volverse poco escalable. Se puede hacer, por supuesto, pero exige mucha disciplina y una arquitectura de componentes bien pensada.

MJML vs HTML tradicional: comparación práctica

Para elegir entre MJML y HTML tradicional, conviene comparar ambos enfoques según criterios concretos.

Facilidad de uso

MJML suele ser más fácil de usar. Su sintaxis es más clara y permite crear estructuras responsive sin escribir todo el HTML manualmente.

HTML tradicional requiere más conocimiento técnico y más atención a los detalles.

Control del resultado

El HTML tradicional gana en control. Si necesitas decidir exactamente cómo será el código final, escribir a mano sigue siendo la opción más directa.

MJML permite personalización, pero trabaja dentro de las reglas de su sistema.

Velocidad de desarrollo

MJML suele ser más rápido, sobre todo para emails estándar: newsletters, promociones, emails de bienvenida o comunicaciones transaccionales.

HTML tradicional puede ser más lento porque exige escribir y revisar más código.

Compatibilidad

La compatibilidad no depende solo de la herramienta. Depende del código final, de las pruebas y de los clientes de correo objetivo.

MJML genera una base bastante preparada, pero no sustituye el proceso de testeo. HTML tradicional puede ser igual de compatible o más, siempre que lo escriba alguien con experiencia en email development.

Mantenimiento

MJML suele ser más mantenible porque el código fuente es más breve y legible.

HTML tradicional puede mantenerse bien si existe una estructura clara, pero tiende a volverse más complejo a medida que crece el número de plantillas.

Cuándo conviene usar MJML

MJML es una buena elección cuando necesitas crear emails responsive de forma rápida, consistente y mantenible.

Puede ser especialmente útil si vas a crear newsletters recurrentes, necesitas varias plantillas similares, quieres reducir errores técnicos, el equipo no tiene mucha experiencia en HTML email, buscas un flujo de trabajo más claro o necesitas reutilizar bloques.

Casos ideales para MJML

MJML encaja muy bien en newsletters corporativas, emails de bienvenida, emails de confirmación, recuperación de contraseña, campañas promocionales, resúmenes mensuales, emails educativos y secuencias automatizadas.

En todos estos casos, la estructura suele ser relativamente estándar: cabecera, bloque principal, contenido, llamada a la acción y footer.

Cuándo conviene usar HTML tradicional

El HTML tradicional puede ser mejor cuando necesitas control total o trabajas con restricciones muy concretas.

Puede interesarte usar HTML tradicional si necesitas personalizar mucho el HTML final, trabajas con plantillas heredadas, tu plataforma de envío modifica el código, tienes requisitos estrictos de compatibilidad, necesitas aplicar hacks específicos o el diseño es muy particular.

Casos ideales para HTML tradicional

El HTML tradicional encaja mejor en emails corporativos muy controlados, plantillas antiguas ya validadas, campañas con requisitos técnicos específicos, sistemas donde no se quiere añadir una fase de compilación y proyectos donde cada detalle visual debe ajustarse manualmente.

En estos casos, la precisión puede pesar más que la velocidad.

Buenas prácticas para decidir entre MJML y HTML

La mejor elección depende del proyecto. No se trata de usar MJML porque sea más cómodo ni HTML tradicional porque parezca más profesional. Se trata de elegir la herramienta que mejor responda a las necesidades reales.

Evalúa la frecuencia de creación

Si vas a crear un email puntual, HTML tradicional puede ser suficiente. Pero si vas a producir emails de forma recurrente, MJML puede ahorrarte mucho tiempo.

Evalúa el nivel técnico del equipo

Si el equipo no tiene experiencia en email development, MJML reduce la barrera de entrada. Si el equipo ya domina HTML email, el HTML tradicional puede seguir siendo una opción sólida.

Evalúa el diseño

Si el diseño es estándar, MJML encaja muy bien. Si el diseño es muy personalizado, quizá necesites HTML tradicional o una combinación de ambos.

Evalúa el flujo de trabajo

Si trabajas con herramientas modernas, control de versiones y procesos de build, integrar MJML es bastante natural. Si todo ocurre dentro de una plataforma visual, quizá el HTML tradicional o el editor propio de la herramienta resulten más prácticos.

Una solución híbrida puede ser la más inteligente

En muchos casos, la mejor opción no es elegir entre MJML o HTML tradicional, sino combinarlos.

Puedes crear la estructura principal en MJML, compilar el HTML y después revisar o ajustar el resultado si es necesario. Este enfoque permite ganar velocidad sin renunciar del todo al control.

También puedes usar MJML para plantillas recurrentes y HTML tradicional para casos especiales.

Errores comunes al comparar MJML vs HTML

Al comparar MJML vs HTML, es fácil caer en algunas ideas demasiado simplificadas.

Pensar que MJML lo soluciona todo

MJML ayuda mucho, pero no elimina todos los problemas del email. Las pruebas siguen siendo necesarias.

Pensar que HTML tradicional siempre es mejor

El control total puede ser útil, pero también implica más trabajo. Si el código se vuelve difícil de mantener, ese control puede convertirse en deuda técnica.

Diseñar emails como si fueran landing pages

Un email no tiene el mismo contexto que una página web. El usuario lo abre en una bandeja de entrada, muchas veces desde el móvil y con poco tiempo de atención.

Por eso, conviene cuidar mucho la claridad del mensaje, la jerarquía visual y las llamadas a la acción. Si usas botones o enlaces, también es importante que sean comprensibles. En este punto, puede ayudarte el artículo sobre por qué los enlaces tipo “haz clic aquí” son un problema de accesibilidad.

No probar antes de enviar

Este error afecta tanto a MJML como a HTML tradicional. Da igual cómo hayas creado el email: si no lo pruebas, estás asumiendo riesgos.

Un email puede verse perfecto en el editor y fallar después en un cliente concreto. Por eso, las pruebas deberían formar parte del proceso, no ser un paso opcional.

Preguntas frecuentes sobre MJML vs HTML tradicional

¿MJML reemplaza completamente al HTML tradicional?

No. MJML no reemplaza el HTML tradicional, sino que lo abstrae. Tú escribes MJML y la herramienta genera HTML. Para trabajar bien con MJML, sigue siendo recomendable entender cómo funciona el HTML email, especialmente si necesitas depurar problemas de compatibilidad.

¿MJML es mejor para crear un html email responsive?

En muchos casos, sí. MJML facilita la creación de un html email responsive porque ofrece componentes pensados para adaptarse a diferentes tamaños de pantalla. Sin embargo, no elimina la necesidad de probar el email en clientes reales ni garantiza que todos los diseños funcionen igual en todas partes.

¿Cuándo debería usar HTML tradicional en lugar de MJML?

Deberías usar HTML tradicional cuando necesites control total sobre el código final, cuando trabajes con restricciones muy específicas o cuando el diseño requiera soluciones que MJML no resuelve fácilmente. También puede ser útil si ya tienes plantillas heredadas bien probadas.

MJML o HTML tradicional: elegir con criterio técnico

La comparación MJML vs HTML tradicional para emails no debería verse como una batalla entre lo moderno y lo clásico. En realidad, se trata de elegir el nivel de abstracción adecuado para cada proyecto.

MJML es una herramienta muy valiosa cuando necesitas crear emails responsive de forma rápida, clara y mantenible. Reduce la complejidad del HTML email, evita parte del trabajo repetitivo y permite centrarte más en la estructura, el contenido y la experiencia de lectura.

El HTML tradicional, por su parte, sigue siendo importante. Te da control, precisión y una comprensión más profunda del medio. En proyectos complejos o con requisitos muy concretos, puede ser la opción más segura.

La mejor decisión suele estar en el equilibrio. Puedes usar MJML para ganar velocidad y mantener una base técnica más limpia, pero cuanto mejor entiendas el HTML que se genera por debajo, más preparada estarás para resolver problemas reales.

Al final, un buen email responsive no es solo el que se ve bonito en una vista previa. Es el que llega bien, se lee bien, funciona en distintos clientes de correo y guía al usuario hacia la acción sin fricción innecesaria.

Animaciones CSS: guía básica para empezar desde cero

Las animaciones CSS son una de esas herramientas que pueden transformar una interfaz sencilla en una experiencia más clara, fluida y agradable. Pero también pueden convertirse en ruido visual si se usan sin intención. Por eso, antes de empezar a añadir movimiento a botones, tarjetas, menús o ilustraciones, conviene entender algo importante: animar con CSS no consiste en decorar por decorar, sino en acompañar al usuario.

Una buena animación puede ayudar a explicar qué está pasando en una interfaz. Puede indicar que un botón es interactivo, que un menú se ha abierto, que una tarjeta ha cambiado de estado o que una acción se ha completado correctamente. En cambio, una animación excesiva, lenta o mal planteada puede aumentar la carga cognitiva, distraer y empeorar la experiencia.

En esta guía básica sobre animaciones CSS vamos a ver desde cero qué son, cuándo usarlas, qué diferencia hay entre transition y animation, cómo funcionan los @keyframes, qué propiedades conviene animar y qué buenas prácticas deberías tener presentes si quieres crear animaciones web útiles, accesibles y mantenibles.

La idea de este artículo es que funcione como un post pilar: una página central desde la que puedas entender los conceptos principales y, después, profundizar en temas concretos como microinteracciones, efectos hover, menús animados, loaders, animaciones accesibles o ilustraciones CSS más complejas. Si también te interesa la parte más visual del CSS, puedes complementar esta guía con el artículo sobre cómo dibujar formas básicas con CSS.

Qué son las animaciones CSS

Las animaciones CSS permiten modificar visualmente uno o varios estilos de un elemento a lo largo del tiempo. En lugar de que un cambio ocurra de forma brusca, puedes hacer que ese cambio sea progresivo.

Por ejemplo, imagina un botón que cambia de color cuando pasas el ratón por encima. Sin animación, el color cambia de golpe. Con una transición, ese cambio puede hacerse de forma suave:

.button {
  background-color: #cc2b5e;
  transition: background-color 0.3s ease;
}

.button:hover {
  background-color: #753a88;
}

Este pequeño detalle ya mejora la percepción de la interfaz. El usuario siente que el elemento responde de forma más natural.

CSS permite crear movimiento principalmente de dos formas: mediante transiciones y mediante animaciones con @keyframes. Las transiciones sirven para animar el cambio entre dos estados de un elemento, por ejemplo un estado normal y un estado :hover. Las animaciones con @keyframes, en cambio, permiten definir varios pasos intermedios dentro de una secuencia más controlada.

Por qué usar animaciones CSS en una web

Las animaciones no deberían estar ahí solo porque “quedan bonitas”. En diseño de interfaces, el movimiento tiene sentido cuando ayuda a comunicar mejor.

Una animación puede cumplir varias funciones dentro de una web:

  • Dar feedback visual.
  • Guiar la atención del usuario.
  • Explicar una relación entre elementos.
  • Suavizar cambios de estado.
  • Hacer que una interfaz se sienta más cuidada.
  • Reforzar la personalidad visual de una marca.

Por ejemplo, una tarjeta que se eleva ligeramente al pasar el cursor comunica que es clicable. Un panel que aparece desde un lateral ayuda a entender de dónde viene ese contenido. Un icono que gira al abrir un acordeón indica que algo ha cambiado de estado.

Ahora bien, también hay que tener cuidado. Si todo se mueve, nada destaca. Una web llena de efectos puede generar cansancio visual y hacer que el usuario tarde más en decidir qué hacer. Aquí conviene pensar en algo muy relacionado con la experiencia de usuario: la diferencia entre captar la atención y aumentar la carga cognitiva. Una animación útil reduce fricción. Una animación innecesaria puede añadir ruido.

Si quieres profundizar más en cómo las decisiones visuales afectan a la comprensión de una interfaz, te puede interesar el artículo sobre HTML semántico y accesibilidad web, porque muchas veces la claridad de una interfaz empieza mucho antes de añadir movimiento.

Transiciones CSS: el primer paso para animar con CSS

Las transiciones CSS son la forma más sencilla de empezar a animar con CSS. Sirven para suavizar el cambio entre dos valores de una propiedad.

Cómo funciona una transición

Una transición necesita, como mínimo, dos cosas: una propiedad que vaya a cambiar y una duración para ese cambio.

.card {
  transform: translateY(0);
  transition: transform 0.25s ease;
}

.card:hover {
  transform: translateY(-8px);
}

Aquí estamos diciendo que la tarjeta parte de su posición original y, cuando el usuario pasa el cursor por encima, se desplaza ligeramente hacia arriba. Ese cambio no sucede de golpe, sino durante 0.25s.

La propiedad transition es una forma abreviada de declarar varias cosas a la vez: qué propiedad se anima, cuánto dura, qué curva de aceleración utiliza y si tiene retraso.

Propiedades principales de transition

Cuando trabajes con transiciones, estas son las propiedades que más vas a utilizar:

.element {
  transition-property: transform;
  transition-duration: 0.3s;
  transition-timing-function: ease;
  transition-delay: 0s;
}

También puedes escribirlo de forma abreviada:

.element {
  transition: transform 0.3s ease 0s;
}

La propiedad transition-property indica qué propiedad se va a animar. transition-duration define la duración. transition-timing-function controla el ritmo de la animación. Y transition-delay permite retrasar el inicio.

Cuándo usar transition

Usa transition cuando quieras animar un cambio sencillo entre dos estados. Es ideal para efectos :hover, estados :focus, botones, tarjetas, enlaces, cambios de color, cambios de opacidad o pequeños desplazamientos.

.link {
  color: #020101;
  text-decoration-thickness: 1px;
  transition: color 0.2s ease, text-decoration-thickness 0.2s ease;
}

.link:hover {
  color: #cc2b5e;
  text-decoration-thickness: 3px;
}

Este tipo de microinteracción puede mejorar mucho la experiencia sin añadir complejidad. Además, es una buena puerta de entrada si estás empezando a animar con CSS.

Animaciones CSS con @keyframes

Cuando necesitas más control que una simple transición, entran en juego las animaciones con @keyframes.

Una animación CSS se compone de dos partes principales: una regla @keyframes, donde defines los pasos de la animación, y una propiedad animation, donde aplicas esa animación a un elemento.

Qué es @keyframes

La regla @keyframes define cómo cambia un elemento durante una animación. Puedes usar from y to, o porcentajes como 0%, 50% y 100%.

@keyframes fadeIn {
  from {
    opacity: 0;
    transform: translateY(16px);
  }

  to {
    opacity: 1;
    transform: translateY(0);
  }
}

.hero-title {
  animation: fadeIn 0.6s ease-out both;
}

En este caso, el título aparece progresivamente y sube ligeramente desde abajo. Es una animación típica para introducir contenido en pantalla.

Diferencia entre from/to y porcentajes

Puedes escribir una animación sencilla así:

@keyframes scaleIn {
  from {
    transform: scale(0.9);
    opacity: 0;
  }

  to {
    transform: scale(1);
    opacity: 1;
  }
}

Pero si necesitas más control, puedes usar porcentajes:

@keyframes bounceSoft {
  0% {
    transform: translateY(0);
  }

  50% {
    transform: translateY(-10px);
  }

  100% {
    transform: translateY(0);
  }
}

Los porcentajes permiten definir puntos intermedios. Esto es útil para animaciones más elaboradas, como rebotes, loaders, entradas escalonadas o pequeños efectos decorativos.

Propiedades principales de animation

La propiedad animation también puede escribirse de forma abreviada. Agrupa propiedades como animation-name, animation-duration, animation-timing-function, animation-delay, animation-iteration-count, animation-direction, animation-fill-mode y animation-play-state.

.badge {
  animation: pulse 1.5s ease-in-out infinite;
}

Aquí estamos diciendo que el elemento usará la animación pulse, durará 1.5s, tendrá una curva ease-in-out y se repetirá infinitamente.

La versión extendida sería:

.badge {
  animation-name: pulse;
  animation-duration: 1.5s;
  animation-timing-function: ease-in-out;
  animation-iteration-count: infinite;
}

Transition vs animation: cuándo usar cada una

Una de las dudas más habituales al empezar con CSS animation es cuándo usar transition y cuándo usar animation.

Usa transition cuando hay un cambio de estado

Las transiciones son perfectas cuando el elemento cambia como respuesta a una interacción o a una clase añadida con JavaScript.

.menu {
  opacity: 0;
  transform: translateY(-8px);
  transition: opacity 0.25s ease, transform 0.25s ease;
}

.menu.is-open {
  opacity: 1;
  transform: translateY(0);
}

Aquí el menú cambia entre cerrado y abierto. La transición suaviza ese cambio.

Usa animation cuando necesitas una secuencia propia

Las animaciones con @keyframes son más adecuadas cuando el movimiento tiene una secuencia definida que no depende únicamente de un cambio entre dos estados.

Por ejemplo, usarías animation para crear un loader, un icono que pulsa, una ilustración animada, una entrada de contenido o una animación que se repite.

@keyframes rotate {
  to {
    transform: rotate(360deg);
  }
}

.loader {
  animation: rotate 1s linear infinite;
}

En resumen: si solo necesitas suavizar un cambio, usa transition; si necesitas definir una secuencia, usa animation y @keyframes.

Propiedades recomendadas para animar

No todas las propiedades CSS se comportan igual cuando las animas. Algunas son más eficientes y otras pueden afectar al rendimiento de la página.

Prioriza transform y opacity

Cuando sea posible, conviene animar transform y opacity. Son dos propiedades especialmente útiles porque permiten crear muchos efectos visuales sin obligar al navegador a recalcular constantemente la estructura de la página.

.element {
  transition: transform 0.3s ease, opacity 0.3s ease;
}

Con transform puedes crear desplazamientos, escalados, rotaciones e inclinaciones:

.box:hover {
  transform: translateY(-6px) scale(1.02);
}

Con opacity puedes crear apariciones y desapariciones suaves:

.tooltip {
  opacity: 0;
  transition: opacity 0.2s ease;
}

.tooltip.is-visible {
  opacity: 1;
}

Evita animar propiedades costosas

Siempre que puedas, evita animar propiedades como width, height, top, left, margin o padding. No significa que estén prohibidas, pero sí que deberías usarlas con cuidado.

Por ejemplo, en lugar de animar top, suele ser mejor animar transform: translateY().

Menos recomendable:

.modal {
  top: -40px;
  transition: top 0.3s ease;
}

.modal.is-open {
  top: 0;
}

Mejor:

.modal {
  transform: translateY(-40px);
  transition: transform 0.3s ease;
}

.modal.is-open {
  transform: translateY(0);
}

Visualmente el resultado puede ser parecido, pero la segunda opción suele ser más eficiente y más fácil de mantener.

Curvas de animación: el papel del easing

La duración de una animación importa, pero el ritmo también. Ahí entra en juego el concepto de easing, que define cómo progresa la animación a lo largo del tiempo.

No es lo mismo una animación completamente lineal que una animación que empieza despacio, acelera y termina suavemente.

Valores habituales de timing-function

Algunos valores comunes son:

.element {
  transition-timing-function: ease;
}
.element {
  transition-timing-function: linear;
}
.element {
  transition-timing-function: ease-in;
}
.element {
  transition-timing-function: ease-out;
}
.element {
  transition-timing-function: ease-in-out;
}

Cuándo usar cada curva

Para interfaces, ease y ease-out suelen funcionar bien en muchas situaciones porque hacen que el movimiento se sienta más natural.

  • linear: útil para loaders o rotaciones constantes.
  • ease: buena opción general.
  • ease-in: empieza lento y termina más rápido.
  • ease-out: empieza rápido y termina suave.
  • ease-in-out: suaviza tanto la entrada como la salida.
.toast {
  animation: slideIn 0.35s ease-out both;
}

En una notificación, ease-out suele tener sentido porque queremos que aparezca con cierta agilidad y se asiente de forma suave.

Ejemplos básicos de animaciones CSS

Veamos algunos ejemplos prácticos que puedes usar como punto de partida. La idea no es copiar y pegar sin pensar, sino entender el patrón para adaptarlo después a tus propios componentes.

Botón con hover suave

.button {
  display: inline-flex;
  align-items: center;
  justify-content: center;
  padding: 0.85rem 1.25rem;
  border-radius: 999px;
  background: #cc2b5e;
  color: #ffffff;
  font-weight: 700;
  text-decoration: none;
  transition: transform 0.2s ease, background-color 0.2s ease;
}

.button:hover {
  transform: translateY(-2px);
  background: #753a88;
}

Este patrón es sencillo, pero muy útil. El botón responde visualmente sin resultar exagerado.

Tarjeta que aparece al cargar

@keyframes cardEnter {
  from {
    opacity: 0;
    transform: translateY(24px);
  }

  to {
    opacity: 1;
    transform: translateY(0);
  }
}

.card {
  animation: cardEnter 0.5s ease-out both;
}

Aquí usamos both para que el elemento conserve los estilos del primer y último fotograma cuando corresponda.

Loader circular

@keyframes spin {
  to {
    transform: rotate(360deg);
  }
}

.loader {
  width: 2rem;
  height: 2rem;
  border: 3px solid #f8e0ea;
  border-top-color: #cc2b5e;
  border-radius: 50%;
  animation: spin 0.8s linear infinite;
}

En este caso, linear tiene sentido porque queremos una rotación constante.

Aparición escalonada de elementos

@keyframes fadeUp {
  from {
    opacity: 0;
    transform: translateY(16px);
  }

  to {
    opacity: 1;
    transform: translateY(0);
  }
}

.list-item {
  animation: fadeUp 0.45s ease-out both;
}

.list-item:nth-child(2) {
  animation-delay: 0.1s;
}

.list-item:nth-child(3) {
  animation-delay: 0.2s;
}

.list-item:nth-child(4) {
  animation-delay: 0.3s;
}

Este recurso es útil para listas, grids de tarjetas o bloques de contenido. Eso sí: úsalo con moderación. Si una página tiene muchos elementos y todos aparecen con retraso, la experiencia puede volverse lenta.

Si estás trabajando con ilustraciones CSS, este tipo de animaciones también puede combinarse con técnicas como pseudo-elementos o recortes visuales. En ese caso, puedes ampliar el tema con el artículo sobre pseudo-elementos en CSS o con la guía sobre clip-path en CSS.

Accesibilidad en animaciones CSS

La accesibilidad es un punto fundamental cuando hablamos de animaciones web. No todas las personas perciben el movimiento de la misma manera. Para algunos usuarios, ciertas animaciones pueden provocar mareo, incomodidad o dificultad para concentrarse.

Por eso, CSS ofrece la media feature prefers-reduced-motion, que permite detectar si una persona ha activado en su sistema una preferencia para reducir el movimiento no esencial.

Cómo usar prefers-reduced-motion

Una forma habitual de aplicarlo es reducir o eliminar animaciones cuando el usuario ha indicado esa preferencia:

@media (prefers-reduced-motion: reduce) {
  *,
  *::before,
  *::after {
    animation-duration: 0.01ms !important;
    animation-iteration-count: 1 !important;
    scroll-behavior: auto !important;
    transition-duration: 0.01ms !important;
  }
}

Este enfoque es bastante global. En proyectos reales, también puedes crear alternativas más cuidadas en lugar de eliminar todo de golpe.

@media (prefers-reduced-motion: reduce) {
  .hero-title {
    animation: none;
  }

  .card:hover {
    transform: none;
  }
}

Animar no debería bloquear la comprensión

Una animación accesible debería cumplir estas ideas:

  • No debe ser imprescindible para entender el contenido.
  • No debe impedir usar la interfaz.
  • No debe ejecutarse de forma infinita sin motivo.
  • No debe parpadear agresivamente.
  • No debe generar desplazamientos inesperados.
  • Debe poder reducirse si el usuario lo necesita.

Una buena regla práctica es esta: si quitas la animación, la interfaz debería seguir funcionando y entendiéndose perfectamente.

También es importante no olvidar los estados de teclado. Si una animación acompaña el estado :hover, muchas veces debería contemplar también :focus-visible. Puedes profundizar en esta parte en el artículo sobre focus visible y navegación con teclado.

Buenas prácticas para crear animaciones CSS

Crear buenas animaciones no depende solo de saber escribir @keyframes. También implica criterio visual, intención de diseño y cuidado técnico.

1. Empieza con movimientos pequeños

Cuando estás empezando, es fácil pasarse. Una tarjeta no necesita volar por la pantalla para comunicar que es interactiva. A menudo basta con un pequeño cambio de opacidad, color o posición.

.card:hover {
  transform: translateY(-4px);
}

Un movimiento pequeño suele sentirse más elegante y menos invasivo.

2. Usa duraciones cortas

En interfaces, muchas animaciones funcionan bien entre 150ms y 400ms. No es una regla absoluta, pero sí un buen punto de partida.

  • Microinteracciones: 150ms250ms.
  • Entradas de elementos: 300ms500ms.
  • Animaciones decorativas: depende del caso, pero conviene usarlas con cuidado.

Una animación demasiado rápida puede pasar desapercibida. Una demasiado lenta puede hacer que la web parezca pesada.

3. Mantén consistencia

Si cada botón, tarjeta y modal usa una duración diferente, la interfaz puede sentirse caótica. Es mejor definir un pequeño sistema de tiempos:

:root {
  --duration-fast: 150ms;
  --duration-base: 250ms;
  --duration-slow: 400ms;
  --ease-base: ease;
}

Y después reutilizarlo:

.button {
  transition: transform var(--duration-base) var(--ease-base);
}

Esto ayuda a que el proyecto sea más mantenible.

4. No animes todo

Una web con demasiadas animaciones puede parecer menos profesional. El movimiento debe tener jerarquía. Antes de añadir una animación, pregúntate si ayuda a entender algo, si aporta feedback, si guía la atención o si simplemente está ahí porque se puede hacer.

Si no cumple ninguna función clara, probablemente sobra.

Errores comunes al empezar con CSS animation

Cuando empiezas a trabajar con CSS animation, es normal cometer algunos errores. Lo importante es detectarlos pronto para que las animaciones no perjudiquen la experiencia.

Animar propiedades equivocadas

Uno de los errores más frecuentes es animar propiedades que afectan al layout cuando podrías usar transform.

Menos recomendable:

.box:hover {
  width: 120%;
}

Mejor:

.box:hover {
  transform: scale(1.05);
}

Usar infinite sin necesidad

Las animaciones infinitas deben reservarse para casos concretos, como loaders o pequeños indicadores de actividad. Si un elemento decorativo se mueve todo el tiempo, puede distraer mucho.

.icon {
  animation: pulse 1s infinite;
}

Antes de usar algo así, pregúntate si realmente necesita repetirse siempre.

Crear animaciones demasiado largas

Una animación larga puede parecer elegante en una demo, pero molesta en una interfaz real. El usuario no quiere esperar a que la web termine de “presentarse” para poder interactuar.

Olvidar el estado focus

Muchas veces se anima :hover, pero se olvida :focus-visible. Esto deja fuera a quienes navegan con teclado.

.button:hover,
.button:focus-visible {
  transform: translateY(-2px);
}

Las animaciones también deben acompañar la accesibilidad de la interacción, no solo el uso con ratón.

Cómo organizar animaciones CSS en un proyecto real

Cuando un proyecto crece, conviene evitar animaciones sueltas y repetidas por todo el CSS. Puedes crear una pequeña arquitectura de movimiento para que todo sea más coherente.

Variables para tiempos y curvas

:root {
  --motion-duration-fast: 150ms;
  --motion-duration-base: 250ms;
  --motion-duration-slow: 400ms;

  --motion-ease-standard: ease;
  --motion-ease-enter: ease-out;
  --motion-ease-exit: ease-in;
}

Clases reutilizables

.animate-fade-up {
  animation: fadeUp var(--motion-duration-slow) var(--motion-ease-enter) both;
}

.transition-base {
  transition-duration: var(--motion-duration-base);
  transition-timing-function: var(--motion-ease-standard);
}

Keyframes centralizados

@keyframes fadeUp {
  from {
    opacity: 0;
    transform: translateY(16px);
  }

  to {
    opacity: 1;
    transform: translateY(0);
  }
}

Este enfoque hace que las animaciones sean más coherentes y fáciles de ajustar. Si más adelante decides que las entradas son demasiado lentas, puedes cambiar una variable en lugar de revisar decenas de componentes.

Una nota sobre diseño responsive

También conviene probar las animaciones en distintos tamaños de pantalla. Un desplazamiento que se ve sutil en escritorio puede sentirse excesivo en móvil. Si trabajas mucho con composición visual en CSS, te recomiendo revisar también el artículo sobre cómo adaptar ilustraciones CSS a distintos tamaños de pantalla.

Animaciones CSS como parte de una estrategia de contenidos

Este artículo está pensado como una guía base sobre animaciones CSS, pero el tema da para mucho más. Por eso tiene sentido usarlo como página central de un cluster de contenidos.

Desde aquí puedes enlazar, por ejemplo, a artículos más específicos sobre:

  • Cómo usar transition en CSS.
  • Cómo crear animaciones con @keyframes.
  • Efectos hover modernos con CSS.
  • Animaciones CSS para botones.
  • Cómo animar menús responsive.
  • Loaders CSS sin JavaScript.
  • Animaciones accesibles con prefers-reduced-motion.
  • Errores de rendimiento al animar con CSS.
  • Microinteracciones CSS para mejorar la UX.
  • Diferencias entre animaciones CSS y animaciones JavaScript.

Esta estructura ayuda tanto al usuario como al SEO. El usuario encuentra una ruta de aprendizaje clara. Y Google puede entender mejor la relación semántica entre los artículos del sitio.

Un post pilar no debería intentar resolver todos los temas con profundidad extrema. Su función es ordenar el mapa, explicar los conceptos base y derivar hacia contenidos complementarios más concretos.

Preguntas frecuentes sobre animaciones CSS

¿Qué diferencia hay entre transition y animation en CSS?

transition sirve para suavizar el cambio entre dos estados de un elemento, por ejemplo cuando un botón pasa de su estado normal a :hover. animation, en cambio, permite crear una secuencia más completa mediante @keyframes, con pasos intermedios, repeticiones, retrasos y mayor control.

¿Qué propiedades CSS conviene animar?

Siempre que sea posible, conviene animar transform y opacity, porque suelen ser más eficientes para el navegador. Con transform puedes crear desplazamientos, escalados y rotaciones. Con opacity puedes controlar apariciones y desapariciones suaves.

¿Las animaciones CSS son mejores que las animaciones con JavaScript?

No siempre. Las animaciones CSS son ideales para microinteracciones, transiciones sencillas, loaders básicos y efectos visuales ligados a estilos. JavaScript puede ser más adecuado cuando necesitas controlar una animación de forma dinámica, responder a eventos complejos, sincronizar estados o crear interacciones avanzadas. La mejor opción depende del problema que quieras resolver.

Movimiento con intención

Las animaciones CSS son una herramienta poderosa, pero su valor no está en el movimiento por sí mismo. Su valor está en cómo ese movimiento ayuda a que una interfaz se entienda mejor.

Una buena animación no interrumpe. No compite con el contenido. No obliga al usuario a esperar. Simplemente acompaña: guía la mirada, suaviza los cambios, refuerza la interacción y hace que la experiencia se sienta más cuidada.

Si estás empezando desde cero, no necesitas memorizar todas las propiedades de golpe. Empieza con transition, practica con transform y opacity, crea tus primeros @keyframes y observa cómo cambia la percepción de una interfaz cuando el movimiento tiene intención.

Animar con CSS no es añadir efectos porque sí. Es tomar decisiones pequeñas, pero importantes, sobre cómo se comporta una web. Y cuando esas decisiones están bien pensadas, las animaciones dejan de ser un adorno para convertirse en parte de la experiencia de usuario.

Cómo crear tu primera newsletter responsive con MJML

Crear una newsletter responsive puede parecer sencillo hasta que llega el momento de maquetarla de verdad. En una página web trabajas con CSS moderno, media queries, flexbox, grid y navegadores bastante predecibles. En cambio, cuando diseñas un email, entras en un entorno mucho más delicado: cada cliente de correo interpreta el HTML y el CSS a su manera.

Gmail, Outlook, Apple Mail o Yahoo Mail no siempre se comportan igual. Algunas propiedades CSS funcionan bien en unos clientes y fallan en otros. Además, muchos emails siguen dependiendo de estructuras basadas en tablas para garantizar una visualización aceptable. Por eso, crear un email responsive HTML desde cero puede ser bastante más complejo de lo que parece.

Aquí es donde entra en juego MJML, una herramienta pensada para simplificar la maquetación de emails responsive. En lugar de escribir directamente todo el HTML final, puedes trabajar con una sintaxis más clara, basada en componentes, y dejar que MJML genere el código compatible con email.

Antes de continuar: si todavía no tienes claro qué es esta herramienta o por qué se utiliza tanto en email marketing, te recomiendo leer primero el artículo Qué es MJML y por qué facilita la maquetación de emails responsive. Te ayudará a entender mejor el contexto antes de empezar con este tutorial práctico.

En esta guía vamos a ver cómo crear tu primera newsletter responsive con MJML paso a paso, desde la estructura inicial hasta algunas buenas prácticas para que el resultado sea más limpio, legible y fácil de adaptar.

Qué necesitas antes de crear una newsletter responsive con MJML

Antes de abrir el editor y empezar a escribir etiquetas, conviene aclarar una idea importante: una newsletter no es una página web en miniatura. Aunque utilice HTML, CSS, imágenes y enlaces, sus reglas son diferentes.

En una web puedes apoyarte en muchas propiedades modernas y confiar en que los navegadores actuales las van a interpretar correctamente. En email marketing, en cambio, tienes que pensar en compatibilidad, peso del archivo, legibilidad, estructura, accesibilidad y comportamiento en móvil.

MJML ayuda precisamente porque reduce parte de esa complejidad. En vez de escribir tablas anidadas, estilos inline y condicionales específicos, puedes trabajar con componentes como <mj-section>, <mj-column>, <mj-text>, <mj-image> o <mj-button>.

Después, MJML se encarga de convertir ese marcado en un HTML más preparado para clientes de correo. Esto no significa que puedas olvidarte por completo de las pruebas, pero sí que partes de una base mucho más cómoda.

Herramientas que puedes utilizar

Para crear tu primera newsletter responsive con MJML tienes varias opciones. Puedes usar el editor online de MJML, instalarlo en tu equipo con Node.js o integrarlo en un flujo de trabajo con npm scripts.

Si estás empezando, el editor online puede ser suficiente para probar la sintaxis y entender cómo se comportan los componentes. Si ya trabajas habitualmente con desarrollo web, probablemente te resulte más cómodo instalar MJML en local y compilar tus archivos desde la terminal.

Un flujo básico de instalación podría ser este:

npm install mjml

Después, podrías compilar un archivo .mjml a HTML con un comando como este:

npx mjml newsletter.mjml -o newsletter.html

De esta forma puedes trabajar sobre un archivo más limpio y generar el HTML final cuando lo necesites para pegarlo en tu plataforma de email marketing.

Estructura básica de una newsletter en MJML

Una newsletter responsive suele tener una estructura bastante reconocible. Normalmente incluye un texto de previsualización, una cabecera, un bloque principal, contenido destacado, una llamada a la acción y un footer con información legal o enlace de baja.

La ventaja de MJML es que esta estructura se puede traducir de forma bastante natural a bloques visuales organizados dentro de <mj-body>.

El esqueleto mínimo de una newsletter con MJML

Este sería un ejemplo muy básico para empezar:

<mjml>
  <mj-head>
    <mj-title>Mi primera newsletter responsive</mj-title>
    <mj-preview>Una newsletter sencilla creada con MJML</mj-preview>
  </mj-head>

  <mj-body background-color="#f5f5f5">
    <mj-section background-color="#ffffff" padding="32px">
      <mj-column>
        <mj-text font-size="24px" font-weight="bold" color="#020101">
          Mi primera newsletter responsive
        </mj-text>

        <mj-text font-size="16px" line-height="1.6" color="#333333">
          Hola, esta es una newsletter creada con MJML para verse bien en escritorio y móvil.
        </mj-text>

        <mj-button background-color="#CC2B5E" color="#ffffff" href="https://tusitio.com">
          Leer más
        </mj-button>
      </mj-column>
    </mj-section>
  </mj-body>
</mjml>

Este ejemplo ya contiene las piezas fundamentales de una newsletter sencilla:

  • <mjml>: etiqueta raíz del documento.
  • <mj-head>: zona para metadatos, estilos globales y vista previa.
  • <mj-preview>: texto que algunos clientes muestran junto al asunto.
  • <mj-body>: cuerpo visual del email.
  • <mj-section>: bloque horizontal de contenido.
  • <mj-column>: columna dentro de una sección.
  • <mj-text>: bloque de texto.
  • <mj-button>: botón de llamada a la acción.

La idea principal es sencilla: tú escribes una estructura más semántica y mantenible, y MJML genera el HTML final necesario para que el email se comporte mejor en diferentes clientes de correo.

Cómo planificar el contenido de tu primera newsletter responsive

Antes de añadir más bloques, conviene detenerse en la estrategia de contenido. Una newsletter no funciona solo porque sea responsive. También necesita tener una jerarquía clara.

El diseño debe ayudar a que la persona entienda rápidamente qué le estás contando, por qué le interesa y qué puede hacer a continuación. Si el mensaje no está claro, el código puede estar perfecto y aun así la newsletter no cumplirá su objetivo.

Define un único objetivo principal

Una buena newsletter suele tener un objetivo dominante. Puede ser llevar tráfico a un artículo, presentar un nuevo servicio, anunciar una promoción, invitar a un evento o compartir novedades de marca.

El problema aparece cuando intentas incluir demasiados objetivos en el mismo email. Si hay muchos mensajes compitiendo entre sí, la persona que recibe la newsletter tiene que hacer más esfuerzo para decidir dónde mirar o en qué enlace hacer clic.

Por eso, para una primera newsletter responsive con MJML, lo ideal es empezar con una estructura sencilla:

  • Un título claro.
  • Una introducción breve.
  • Una imagen o bloque visual si aporta valor.
  • Un cuerpo de texto directo.
  • Un botón de acción principal.
  • Un cierre breve.

Esta estructura permite que el email sea fácil de leer, fácil de escanear y más sencillo de adaptar a móvil.

Piensa primero en móvil

Aunque MJML facilite la adaptación responsive, las decisiones de diseño siguen siendo tuyas. Por eso es importante pensar desde el principio en pantallas pequeñas.

En móvil, una newsletter debe leerse sin esfuerzo. Los titulares tienen que ser claros, los párrafos no deberían ser demasiado largos y los botones deben tener un tamaño cómodo para pulsar con el dedo.

También conviene evitar composiciones demasiado complejas. Las columnas pueden funcionar bien en escritorio, pero en móvil suelen apilarse. Si cada bloque no tiene sentido por sí mismo, la lectura puede volverse confusa.

Un buen email se escanea antes de leerse

Muchas personas no leen una newsletter de arriba abajo. Primero la escanean. Miran el asunto, el preheader, el título principal, algún elemento visual, los subtítulos y el botón.

Por eso, cada bloque debería responder a una pregunta concreta:

  • ¿De qué trata este email?
  • ¿Por qué debería importarme?
  • ¿Qué puedo hacer ahora?
  • ¿Dónde tengo que hacer clic?

Si estas respuestas no están claras, el diseño puede resultar atractivo, pero la newsletter no será tan efectiva.

Ejemplo completo de newsletter responsive con MJML

Ahora vamos a crear una newsletter algo más realista. Imaginemos que quieres enviar un email para compartir un nuevo artículo de tu blog sobre MJML.

<mjml>
  <mj-head>
    <mj-title>Nuevo artículo sobre MJML</mj-title>
    <mj-preview>Aprende a crear tu primera newsletter responsive con MJML.</mj-preview>

    <mj-attributes>
      <mj-all font-family="Arial, sans-serif" />
      <mj-text color="#333333" font-size="16px" line-height="1.6" />
      <mj-button border-radius="8px" font-size="16px" font-weight="bold" />
    </mj-attributes>
  </mj-head>

  <mj-body background-color="#f5f5f5">
    <mj-section background-color="#ffffff" padding="24px 32px 16px">
      <mj-column>
        <mj-text font-size="14px" color="#753A88" font-weight="bold">
          Marta González · Desarrollo web
        </mj-text>
      </mj-column>
    </mj-section>

    <mj-section background-color="#ffffff" padding="16px 32px 24px">
      <mj-column>
        <mj-text font-size="28px" line-height="1.3" font-weight="bold" color="#020101">
          Cómo crear tu primera newsletter responsive con MJML
        </mj-text>

        <mj-text>
          Si alguna vez has intentado maquetar un email responsive a mano, sabrás que no siempre se comporta como una web normal. Por eso MJML puede ayudarte a crear newsletters más limpias, mantenibles y adaptadas a móvil.
        </mj-text>

        <mj-button background-color="#CC2B5E" color="#ffffff" href="https://martagonzalez.dev/blog/como-crear-tu-primera-newsletter-responsive-con-mjml/">
          Leer el artículo completo
        </mj-button>
      </mj-column>
    </mj-section>

    <mj-section background-color="#F8E0EA" padding="24px 32px">
      <mj-column>
        <mj-text font-size="20px" font-weight="bold" color="#020101">
          Qué aprenderás en esta guía
        </mj-text>

        <mj-text>
          Verás cómo funciona la estructura básica de MJML, qué componentes necesitas para empezar y qué buenas prácticas conviene aplicar antes de exportar el HTML final de tu newsletter.
        </mj-text>
      </mj-column>
    </mj-section>

    <mj-section background-color="#ffffff" padding="24px 32px">
      <mj-column>
        <mj-text font-size="18px" font-weight="bold" color="#020101">
          Consejo rápido
        </mj-text>

        <mj-text>
          No empieces diseñando una newsletter demasiado compleja. Primero crea una versión sencilla, comprueba que se lee bien en móvil y después añade bloques secundarios solo si aportan valor.
        </mj-text>
      </mj-column>
    </mj-section>

    <mj-section background-color="#020101" padding="24px 32px">
      <mj-column>
        <mj-text color="#ffffff" font-size="13px" line-height="1.5">
          Recibes este email porque te has suscrito a las novedades del blog.
          Puedes darte de baja en cualquier momento.
        </mj-text>
      </mj-column>
    </mj-section>
  </mj-body>
</mjml>

Este ejemplo ya se parece mucho más a una newsletter real. Tiene identidad, título, introducción, CTA, bloque destacado, consejo adicional y footer. No es una estructura recargada, pero sí suficiente para comunicar un mensaje con claridad.

Si quieres profundizar en la lógica que hay detrás de estos componentes, puedes complementar esta guía con el artículo sobre qué es MJML y cómo facilita la maquetación de emails responsive, donde se explica mejor por qué esta herramienta resulta tan útil frente a la maquetación manual de emails.

Buenas prácticas para una newsletter responsive con MJML

Crear el archivo MJML es solo una parte del proceso. Para que la newsletter funcione bien, también tienes que cuidar la experiencia de lectura, la accesibilidad y la compatibilidad.

Utiliza una anchura segura

En email marketing es habitual trabajar con un ancho aproximado de 600 píxeles para el contenedor principal. Esta medida ayuda a mantener una lectura cómoda en escritorio y facilita la adaptación posterior a móvil.

MJML ya está pensado para trabajar con convenciones habituales en email, pero aun así conviene evitar diseños excesivamente anchos o estructuras con demasiadas columnas.

En una primera newsletter, menos suele ser mejor. Una sección principal, una llamada a la acción y uno o dos bloques secundarios pueden ser más efectivos que una composición demasiado larga.

Cuida el texto alternativo de las imágenes

Si incluyes imágenes en tu newsletter, no dependas de ellas para comunicar todo el mensaje. Algunos clientes de correo pueden bloquearlas por defecto o cargarlas con retraso.

Por eso es importante usar el atributo alt de forma descriptiva:

<mj-image
  src="https://tusitio.com/imagen-newsletter.jpg"
  alt="Ilustración sobre newsletter responsive creada con MJML"
/>

El texto alternativo ayuda a contextualizar la imagen cuando no se carga y mejora la accesibilidad del email.

No abuses de los botones

Una newsletter puede tener varios enlaces, pero debería tener una acción principal muy clara. Si todos los botones tienen el mismo peso visual, ninguno destaca realmente.

Una buena práctica es reservar el botón principal para la acción más importante y utilizar enlaces de texto para acciones secundarias. Así ayudas a que la persona entienda qué esperas que haga después de leer el email.

Revisa el preheader

El preheader es el texto de vista previa que muchos clientes de correo muestran junto al asunto. Es una pieza pequeña, pero puede influir mucho en la apertura del email.

Un preheader genérico como este aporta poco:

<mj-preview>Newsletter de marzo</mj-preview>

En cambio, este otro resulta más concreto:

<mj-preview>Aprende a crear una newsletter responsive con MJML paso a paso.</mj-preview>

La diferencia está en que el segundo anticipa el valor del contenido y refuerza la promesa del asunto.

Errores comunes al crear tu primera newsletter con MJML

Aunque MJML simplifica mucho la maquetación, hay algunos errores habituales que conviene evitar desde el principio.

Tratar el email como si fuera una landing page

Una newsletter no debería tener la misma densidad visual que una página de venta completa. La persona que recibe el email está dentro de su bandeja de entrada, probablemente revisando mensajes de forma rápida.

Por eso conviene reducir la fricción. Menos bloques, menos mensajes simultáneos y una llamada a la acción más clara suelen funcionar mejor que una newsletter demasiado cargada.

No probar el HTML final

MJML genera HTML responsive, pero eso no significa que debas enviar la newsletter sin revisarla. Siempre conviene hacer pruebas antes del envío real.

Revisa especialmente cómo se ve el email en Gmail, Outlook, Apple Mail y en móvil. Comprueba también el modo oscuro, la carga de imágenes, los enlaces, el texto del botón y el footer.

El objetivo no es buscar la perfección visual absoluta en todos los clientes, sino asegurarte de que el mensaje se entiende, se puede leer bien y la acción principal funciona.

Usar imágenes demasiado pesadas

Las imágenes grandes pueden ralentizar la carga del email y empeorar la experiencia, sobre todo en móvil. Además, si el contenido depende demasiado de una imagen, el mensaje puede perder sentido cuando esa imagen no se muestra.

Lo recomendable es optimizar las imágenes antes de subirlas, utilizar dimensiones adecuadas y acompañarlas siempre con texto suficiente.

Olvidar la accesibilidad

Una newsletter responsive también debería ser accesible. No basta con que se adapte al móvil. Tiene que poder leerse con comodidad.

Algunas pautas básicas son utilizar buen contraste entre texto y fondo, elegir tamaños de fuente legibles, escribir botones descriptivos y evitar enlaces poco claros como “haz clic aquí”.

También es importante no comunicar información únicamente mediante color. Si algo es importante, debe quedar claro también por el texto o por la estructura del contenido.

Cómo pasar de MJML a HTML para enviar tu newsletter

Cuando termines tu archivo .mjml, tendrás que convertirlo a HTML. Ese será el código que podrás pegar o importar en tu herramienta de email marketing.

Si trabajas desde la terminal, el proceso puede ser tan sencillo como este:

npx mjml newsletter.mjml -o newsletter.html

Después puedes abrir el archivo newsletter.html, revisar el resultado y llevar ese código a la plataforma desde la que vayas a enviar tu campaña.

Checklist antes de enviar tu newsletter

Antes de enviar tu primera newsletter responsive con MJML, revisa esta lista:

  • El asunto es claro y concreto.
  • El preheader complementa el asunto.
  • El diseño se entiende bien en móvil.
  • El CTA principal destaca sin resultar invasivo.
  • Todos los enlaces funcionan correctamente.
  • Las imágenes tienen texto alternativo.
  • El email no depende únicamente de imágenes.
  • El footer incluye la información necesaria.
  • El HTML final se ha probado antes del envío.
  • La newsletter tiene un objetivo principal bien definido.

Esta revisión puede parecer básica, pero evita muchos errores de última hora. En email marketing, los pequeños detalles importan mucho porque, una vez enviado el correo, ya no puedes corregirlo como harías con una página web.

Preguntas frecuentes sobre crear una newsletter responsive con MJML

¿MJML sustituye al HTML en email marketing?

No exactamente. MJML no sustituye al HTML final, sino que te permite escribir una versión más sencilla y legible que después se compila a HTML. Es decir, tú trabajas con MJML, pero la herramienta genera el email responsive HTML que utilizarás en tu plataforma de envío.

¿Necesito saber programar para usar MJML?

No necesitas ser una persona experta, pero sí ayuda tener nociones básicas de HTML y CSS. MJML es más accesible que maquetar emails responsive directamente con tablas, pero sigue siendo una herramienta técnica. Si entiendes la lógica de etiquetas, atributos, secciones y columnas, puedes empezar con ejemplos sencillos e ir avanzando poco a poco.

¿Puedo usar MJML para cualquier tipo de newsletter?

Sí, puedes utilizar MJML para newsletters editoriales, emails promocionales, comunicaciones internas, emails transaccionales o avisos automatizados. Aun así, cada tipo de email necesita una estructura diferente. Una newsletter de blog no debería plantearse igual que una campaña comercial o un email de recuperación de carrito.

Una última idea antes de crear tu primera newsletter

Crear tu primera newsletter responsive con MJML es una forma muy práctica de entrar en el mundo del email marketing sin tener que pelearte desde el primer minuto con tablas anidadas, estilos inline y comportamientos extraños entre clientes de correo.

MJML te permite trabajar con una sintaxis más limpia, ordenar mejor tus bloques y generar un HTML más preparado para email. Sin embargo, la herramienta no lo hace todo por ti.

La calidad de una newsletter depende también de tus decisiones de comunicación: qué mensaje priorizas, cómo estructuras el contenido, qué acción quieres que realice la persona que recibe el email y cómo reduces la fricción para que pueda hacerlo.

Una buena newsletter no es la que tiene más bloques, más botones o más elementos visuales. Es la que se entiende rápido, se lee bien en móvil y acompaña a la persona hacia una acción clara.

Por eso, si estás empezando, mi recomendación es sencilla: crea una primera versión mínima, pruébala, ajústala y aprende de cada envío. Y si quieres reforzar la base antes de seguir avanzando, puedes volver al artículo sobre qué es MJML y por qué facilita la maquetación de emails responsive para entender mejor cómo encaja esta herramienta dentro de un flujo de trabajo de email marketing.