Conversor gratuito de PX a REM

Convierte píxeles a rem y viceversa, con un tamaño de fuente base configurable.

px (valor por defecto del navegador: 16)

Tabla de referencia

PXREM

Cómo funciona

REM significa «root em» y es relativo al tamaño de fuente del elemento raíz. Por defecto, los navegadores usan 16 px. La fórmula es simple: rem = px ÷ base y px = rem × base. Modifica el tamaño base arriba si tu proyecto usa una raíz distinta.

Preguntas frecuentes

¿Por qué usar rem en lugar de px?

Las unidades REM se adaptan al ajuste de tamaño de fuente del usuario en su navegador, mejorando la accesibilidad. Si un usuario aumenta su tamaño de fuente por defecto, los diseños basados en rem se ajustan automáticamente, al contrario que los valores en píxeles, que permanecen fijos.

¿Cuál es la diferencia entre em y rem?

EM es relativo al tamaño de fuente del elemento padre y puede acumularse en los elementos anidados. REM siempre es relativo al tamaño de fuente del elemento raíz (<html>), lo que lo hace más predecible.

¿Qué base usar?

La mayoría de los proyectos usan el valor por defecto del navegador de 16 px. Algunos desarrolladores definen html { font-size: 62.5%; } (10 px) para cálculos más simples. Usa el tamaño de fuente raíz definido para tu proyecto.

Qué es realmente rem

«Rem» significa root em. La especificación CSS Values Level 3 del W3C lo define como «igual al valor calculado de font-size en el elemento raíz», es decir, en el elemento <html>. Los navegadores ponen <html> a 16px por defecto, salvo que se anule, así que en una página sin más 1rem = 16px, 0.5rem = 8px, 1.5rem = 24px, 2rem = 32px.

Si una hoja de estilos declara html { font-size: 20px }, entonces 1rem = 20px para el resto del documento. Si el usuario ha subido el valor predeterminado de su navegador a 24px (un ajuste común para la baja visión), 1rem = 24px incluso sin ninguna anulación de hoja de estilos, y ese es todo el argumento de accesibilidad de rem en una sola frase.

Por qué importa rem: el argumento de accesibilidad

Los navegadores exponen a los usuarios dos mecanismos de escalado diferentes, y se comportan de forma distinta respecto a las unidades:

Por esto un diseño construido en rem respeta la preferencia de accesibilidad del usuario y un diseño construido en px no. El criterio de éxito 1.4.4 de WCAG 2.2 (Cambio de tamaño del texto, nivel AA) exige que el texto pueda ampliarse al menos al 200 % sin pérdida de contenido o funcionalidad. El zoom del navegador por sí solo lo cumple técnicamente, pero los diseños basados en rem lo cumplen de forma más limpia porque respetan el mecanismo más granular del tamaño de fuente predeterminado, que es lo que los usuarios con baja visión ajustan en realidad en su día a día.

La trampa de la composición de em que motiva rem

Antes de rem, la única forma de obtener tipografía escalable en CSS era em, que es relativo al font-size del elemento padre, no de la raíz. El problema clásico: los elementos anidados con tamaños de fuente basados en em se acumulan.

.list { font-size: 1.2em; }
.list .list { font-size: 1.2em; } /* renders at 1.44× the grandparent */
.list .list .list { font-size: 1.2em; } /* now 1.728× */

Tres listas anidadas se hinchan hasta casi el doble del tamaño del cuerpo, lo que casi nunca es la intención. rem resuelve esto anclándose a la raíz cada vez: tres elementos anidados a 1.2rem miden todos 19,2px con independencia de la profundidad de anidamiento. Por esto la mayoría de las hojas de estilos modernas usan rem para font-size y reservan em para las proporciones internas de los componentes (tamaños de icono que deberían coincidir con el texto del botón, relleno dentro de un botón que escala con su etiqueta).

El truco del 62,5 %: matemáticas cómodas, accesibilidad discutible

Un patrón popularizado por Jonathan Snook en su artículo de mayo de 2011: poner html { font-size: 62.5% }. Como 62,5 % × 16 = 10, esto hace que 1rem = 10px por defecto, un cálculo mental cómodo. 1.6rem = 16px, 2.4rem = 24px, 4.8rem = 48px. A los diseñadores les gustaba porque elimina la incómoda aritmética de «dividir entre 16» de cada valor.

La crítica de accesibilidad (planteada en su momento y reforzada en escritos posteriores): poner el tamaño de fuente raíz al 62,5 % encoge en la práctica lo que sea que el usuario haya elegido en las preferencias de su navegador. Un usuario que puso su valor predeterminado a 24px porque tiene baja visión vería el texto del cuerpo a 15px, anulando todo el propósito de usar rem. La refutación moderna consiste en poner la raíz al 62,5 % pero declarar explícitamente el font-size del cuerpo a 1.6rem (de vuelta a 16px), de modo que la anulación del usuario aún se propague en cascada correctamente. Muchos equipos se saltan el truco por completo y conviven con las matemáticas algo menos elegantes.

Cuándo usar rem, cuándo usar px: el enfoque de Comeau

El artículo de Josh W. Comeau «¿px o rem?» (mayo de 2022, actualizado en mayo de 2025) ofrece la heurística de una sola pregunta más útil para esta decisión. Pregunta: «¿Debería este valor aumentar de escala a medida que el usuario incrementa el tamaño de fuente predeterminado de su navegador?» Si sí, usa rem. Si no, usa px.

Según esa prueba:

La prueba de una sola pregunta produce respuestas coherentes a lo largo de miles de decisiones en una base de código, que es la verdadera ventaja: las hojas de estilos resultantes se comportan como los usuarios esperan tanto con el zoom como con la personalización del tamaño de fuente.

Tailwind CSS 4 se pasó a rem en todas partes

Tailwind CSS v4.0 (enero de 2025) incorporó una escala por defecto totalmente basada en rem. Cada token de tipografía (de text-xs 0.75rem a text-9xl 8rem) y cada token de espaciado (p-1 0.25rem, p-4 1rem, m-8 2rem) viene en rem de fábrica. Tailwind 4 deja deliberadamente la raíz <html> en el valor por defecto del navegador de 16px (explícitamente no aplica el truco del 62,5 %) para que las preferencias de accesibilidad del usuario se propaguen en cascada limpiamente. Decenas de millones de proyectos distribuyen ahora sistemas de diseño basados en rem por defecto, que es el argumento más fuerte de que el ecosistema ha convergido.

Tabla de conversión con la raíz predeterminada de 16px

PíxelesRemUso común
8 px0,5 remLa mitad de la unidad base; espaciado pequeño
12 px0,75 remPie de foto / letra pequeña
14 px0,875 remTexto secundario
16 px1 remTexto de cuerpo por defecto
18 px1,125 remCuerpo ligeramente enfatizado
20 px1,25 remPárrafo de entrada
24 px1,5 remEncabezado H4; texto de interfaz grande
32 px2 remEncabezado H3
48 px3 remEncabezado H2 / hero
64 px4 remEncabezado H1 / display

Dónde encaja rem en el conjunto de herramientas moderno

Rem es el valor por defecto correcto para el tipo y el espaciado anclado al tipo, pero no es la respuesta a todos los problemas de diseño. La caja de herramientas moderna también incluye:

Para todo lo demás (texto de cuerpo, encabezados, rellenos, anchos de botón, puntos de ruptura), rem es el camino de menor resistencia y el valor por defecto más accesible.

Más preguntas

¿Y si mi proyecto usa un tamaño de fuente base no predeterminado?

Cambia el campo Tamaño de fuente base de arriba a lo que sea que resuelva el html { font-size: … } de tu proyecto. Las matemáticas de la conversión siguen siendo rem = px ÷ base sea cual sea la base. Si tu base de código usa 18px, 32px se convierte en 1.78rem; a 10px (el truco del 62,5 %) se convierte en 3.2rem. Ten en cuenta que anular el tamaño de fuente raíz tiene implicaciones de accesibilidad para los usuarios que personalizan el valor predeterminado de su navegador; consulta más arriba la discusión sobre el truco del 62,5 %.

¿Por qué 0,625rem no se renderiza exactamente a 10px?

Sí lo hace, matemáticamente, con la raíz predeterminada de 16px: 0.625 × 16 = 10. Pero los navegadores renderizan con precisión de subpíxel y pueden ajustar los valores finales a píxeles de dispositivo enteros, así que un borde de 0.625rem puede a veces parecer ligeramente diferente de un borde fijo de 10px según el DPR del monitor. Para las líneas finas de 1 píxel perfectas al píxel, usa 1px directamente; para todo lo demás, el valor basado en rem está bien.

¿Puedo mezclar rem y px en la misma hoja de estilos?

Sí, y deberías. Usa rem para las cosas que deberían escalar con la preferencia de tamaño de fuente del usuario (la tipografía, el ritmo vertical, los puntos de ruptura) y px para las que no deberían (los bordes, los detalles de los iconos, las sombras decorativas). La pregunta de Comeau «¿esto debería escalar?» es el filtro práctico; la respuesta se corresponde limpiamente con una unidad u otra casi siempre.

¿Las herramientas de compilación convierten px a rem automáticamente?

Sí, los plugins de PostCSS como postcss-pxtorem y postcss-rem-to-responsive-pixel pueden reescribir los valores en px de tu CSS escrito a mano a rem durante el paso de compilación, con umbrales configurables (p. ej., «convierte cualquier cosa ≥ 12px»). Son útiles al migrar una base de código existente con muchos px. Un convertidor en vivo como esta página sigue siendo útil para casos puntuales, consultas de especificaciones de diseño y aprender las matemáticas a mano.

¿Se envía algo a un servidor?

No. La conversión es una sola división, aritmética de JavaScript puro que se ejecuta localmente en tu navegador. Nada de tu entrada sale de la página; la herramienta funciona sin conexión una vez cargada.

Herramientas relacionadas