Conversor gratuito de PX para REM
Converta pixels em rem e vice-versa, com tamanho de fonte base configurável.
Tabela de referência
| PX | REM |
|---|
Como funciona
REM significa « root em » e é relativo ao tamanho de fonte do elemento raiz. Por padrão, os navegadores usam 16 px. A fórmula é simples : rem = px ÷ base e px = rem × base. Altere o tamanho base acima se o seu projeto usar uma raiz diferente.
Perguntas frequentes
Por que usar rem em vez de px ?
As unidades REM se adaptam à configuração de tamanho de fonte do usuário em seu navegador, melhorando a acessibilidade. Se um usuário aumenta seu tamanho de fonte padrão, layouts baseados em rem se ajustam automaticamente, diferentemente dos valores em pixels que permanecem fixos.
Qual a diferença entre em e rem ?
EM é relativo ao tamanho de fonte do elemento pai e pode se acumular em elementos aninhados. REM é sempre relativo ao tamanho de fonte do elemento raiz (<html>), o que o torna mais previsível.
Qual base usar ?
A maioria dos projetos usa o valor padrão do navegador de 16 px. Alguns desenvolvedores definem html { font-size: 62.5%; } (10 px) para cálculos mais simples. Use o tamanho de fonte raiz definido para seu projeto.
O que o rem realmente é
«Rem» significa root em. A spec W3C CSS Values Level 3 o define como «igual ao valor computado de font-size no elemento raiz», ou seja, no elemento <html>. Os navegadores usam <html> como padrão de 16px a menos que seja sobrescrito, então em uma página comum 1rem = 16px, 0.5rem = 8px, 1.5rem = 24px, 2rem = 32px.
Se uma folha de estilo declara html { font-size: 20px }, então 1rem = 20px para o resto do documento. Se o usuário aumentou o padrão do navegador para 24px (um ajuste comum para baixa visão), 1rem = 24px mesmo sem nenhuma sobrescrita na folha de estilo, e esse é todo o argumento de acessibilidade do rem em uma frase.
Por que o rem importa: o argumento da acessibilidade
Os navegadores expõem dois mecanismos de escalonamento diferentes aos usuários, e eles se comportam de forma diferente em relação às unidades:
- Zoom do navegador (Cmd/Ctrl + ou pinça), escala uniformemente a viewport inteira. Um elemento de 16px com 200% de zoom ocupa o mesmo espaço de tela que um elemento de 32px com 100% de zoom. Tanto
pxquantoremescalam de forma idêntica sob o zoom, então o zoom por si só não justifica o rem. - Preferência de tamanho de fonte padrão do navegador: enterrada nas configurações do navegador (
about:preferencesdo Firefox, o Personalizar fontes do Chrome). Quando o usuário muda o «Tamanho de fonte padrão» de 16 para 24 (muito comum para usuários de baixa visão), o elemento<html>começa a computar em 24px. Todo valorremescala automaticamente por 1,5×; todo valorpxfixo permanece exatamente o mesmo.
É por isso que um layout construído em rem respeita a preferência de acessibilidade do usuário e um layout construído em px não. O Critério de Sucesso 1.4.4 da WCAG 2.2 (Redimensionar Texto, Nível AA) exige que o texto possa ser ampliado para pelo menos 200% sem perda de conteúdo ou funcionalidade. O zoom do navegador sozinho passa nisso tecnicamente, mas os layouts baseados em rem passam de forma mais limpa porque respeitam o mecanismo mais granular de tamanho de fonte padrão, que é o que os usuários de baixa visão realmente ajustam no dia a dia.
A cilada de acúmulo do em que motiva o rem
Antes do rem, a única forma de obter uma tipografia escalável no CSS era o em, que é relativo ao tamanho de fonte do elemento pai, não da raiz. O problema clássico: elementos aninhados com tamanhos de fonte baseados em em se acumulam.
.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× */Três listas aninhadas incham para quase o dobro do tamanho do corpo, o que quase nunca é a intenção. O rem resolve isso ancorando à raiz toda vez, três elementos aninhados em 1.2rem são todos 19,2px independentemente da profundidade de aninhamento. É por isso que a maioria das folhas de estilo modernas usa rem para font-size e reserva em para proporções internas de componente (tamanhos de ícone que devem combinar com o texto do botão, padding dentro de um botão que escala com o seu rótulo).
O truque dos 62.5%: matemática conveniente, acessibilidade discutível
Um padrão popularizado por Jonathan Snook no seu artigo de maio de 2011: defina html { font-size: 62.5% }. Como 62.5% × 16 = 10, isso faz 1rem = 10px por padrão, uma conta mental conveniente. 1.6rem = 16px, 2.4rem = 24px, 4.8rem = 48px. Os designers gostavam disso porque remove a aritmética desajeitada de «dividir por 16» de cada valor.
A crítica de acessibilidade (levantada na época e reforçada em textos posteriores): definir o tamanho de fonte da raiz para 62.5% encolhe, na prática, o que quer que o usuário tenha escolhido nas preferências do navegador. Um usuário que definiu o seu padrão para 24px porque tem baixa visão veria o texto do corpo em 15px, anulando todo o propósito de usar rem. A refutação moderna é definir a raiz para 62.5%, mas declarar explicitamente o tamanho de fonte do corpo em 1.6rem (de volta a 16px), para que a sobrescrita do usuário ainda se propague corretamente. Muitas equipes pulam o truque inteiramente e convivem com a matemática um pouco menos elegante.
Quando usar rem, quando usar px: o enquadramento de Comeau
O artigo «px or rem?» de Josh W. Comeau (maio de 2022, atualizado em maio de 2025) oferece a heurística de pergunta única mais útil para essa decisão. Pergunte: «Este valor deveria aumentar conforme o usuário aumenta o tamanho de fonte padrão do navegador?» Se sim, use rem. Se não, use px.
Por esse teste:
- Use rem para: font-size, margens/padding verticais (que estão ligados ao ritmo do tipo), larguras de botão e outros contêineres com formato de conteúdo, larguras máximas de comprimento de linha, breakpoints (para que o layout se reorganize no tamanho ampliado certo para usuários de baixa visão).
- Use px para: bordas (uma linha fina de 1px deve continuar fina), padding/decoração horizontais, raios de sombra, tamanhos de imagem quando a imagem tem uma intenção de pixel fixa, dimensões finas de ícones.
O teste de pergunta única produz respostas consistentes ao longo de milhares de decisões em uma base de código, o que é a verdadeira vitória: as folhas de estilo resultantes se comportam da forma que os usuários esperam tanto sob o zoom quanto sob a personalização do tamanho de fonte.
O Tailwind CSS 4 adotou rem em todo lugar
O Tailwind CSS v4.0 (janeiro de 2025) chegou com uma escala padrão totalmente baseada em rem. Todo token de tipografia (text-xs 0.75rem até text-9xl 8rem) e todo token de espaçamento (p-1 0.25rem, p-4 1rem, m-8 2rem) está em rem de fábrica. O Tailwind 4 deliberadamente deixa a raiz <html> no padrão do navegador de 16px (eles deliberadamente não aplicam o truque dos 62.5%), para que as preferências de acessibilidade do usuário se propaguem de forma limpa. Dezenas de milhões de projetos agora entregam sistemas de design baseados em rem por padrão, o que é o argumento mais forte de que o ecossistema convergiu.
Tabela de conversão na raiz padrão de 16px
| Pixels | Rem | Uso comum |
|---|---|---|
| 8 px | 0.5 rem | Metade da unidade base, espaçamento pequeno |
| 12 px | 0.75 rem | Legenda / letra miúda |
| 14 px | 0.875 rem | Texto secundário |
| 16 px | 1 rem | Padrão do corpo do texto |
| 18 px | 1.125 rem | Corpo levemente enfatizado |
| 20 px | 1.25 rem | Parágrafo de abertura |
| 24 px | 1.5 rem | Título H4; texto de UI grande |
| 32 px | 2 rem | Título H3 |
| 48 px | 3 rem | Título H2 / hero |
| 64 px | 4 rem | Título H1 / display |
Onde o rem se encaixa no kit de ferramentas moderno
O rem é o padrão certo para o tipo e o espaçamento ancorado ao tipo, mas não é a resposta para todo problema de layout. A caixa de ferramentas moderna também inclui:
- clamp() para tipografia fluida,
font-size: clamp(1rem, 0.8rem + 1vw, 1.5rem)define um piso e um teto em rem com um meio dirigido pela viewport. Conversor de unidades CSS - Unidades de viewport (
vw,vhe as mais novassvh/lvh/dvhpara mobile), para seções hero e elementos de sangria total que devem escalar com a viewport em vez de com o tipo. - Unidades de container query (
cqw,cqh), para design dirigido por componente, onde o mesmo componente pode aparecer em larguras diferentes.
Para todo o resto (texto do corpo, títulos, paddings, larguras de botão, breakpoints), o rem é o caminho de menor resistência e o padrão mais acessível.
Mais perguntas
E se o meu projeto usa um tamanho de fonte base não padrão?
Mude o campo Tamanho de fonte base acima para o que quer que o html { font-size: … } do seu projeto resolva. A matemática da conversão continua sendo rem = px ÷ base, independentemente da base. Se a sua base de código usa 18px, 32px vira 1.78rem; em 10px (o truque dos 62.5%) vira 3.2rem. Esteja ciente de que sobrescrever o tamanho de fonte da raiz tem implicações de acessibilidade para usuários que personalizam o padrão do navegador, veja a discussão sobre o truque dos 62.5% acima.
Por que 0.625rem não renderiza exatamente para 10px?
Renderiza, sim, matematicamente, na raiz padrão de 16px, 0.625 × 16 = 10. Mas os navegadores renderizam com precisão de subpixel e podem ajustar os valores finais para pixels inteiros do dispositivo, então uma borda 0.625rem pode ocasionalmente parecer ligeiramente diferente de uma borda 10px codificada à mão, dependendo do DPR do monitor. Para linhas finas de 1 pixel com precisão perfeita, use 1px diretamente; para todo o resto, o valor baseado em rem está bom.
Posso misturar rem e px na mesma folha de estilo?
Sim, e você deveria. Use rem para coisas que devem escalar com a preferência de tamanho de fonte do usuário (tipografia, ritmo vertical, breakpoints) e px para coisas que não devem (bordas, detalhes de ícones, sombras decorativas). A pergunta «isto deveria escalar?» de Comeau é o filtro prático; a resposta mapeia de forma limpa para uma unidade ou a outra quase toda vez.
As ferramentas de build convertem px para rem automaticamente?
Sim, plugins do PostCSS como o postcss-pxtorem e o postcss-rem-to-responsive-pixel podem reescrever os valores em px do seu CSS para rem durante a etapa de build, com limiares configuráveis (por exemplo, «converter qualquer coisa ≥ 12px»). Eles são úteis ao migrar uma base de código existente com muitos px. Um conversor ao vivo como esta página ainda é útil para casos pontuais, consultas de especificação de design e para aprender a conta à mão.
Algo é enviado a um servidor?
Não. A conversão é uma divisão, aritmética JavaScript pura rodando localmente no seu navegador. Nada sobre a sua entrada sai da página; a ferramenta funciona offline depois de carregada.