Conversor de unidades CSS: px, rem, em, %, pt, vw

Um pixel do CSS não é um pixel da sua tela

As unidades absolutas estão presas umas às outras por definição: uma polegada é exatamente 96 pixels, um ponto é 1/72 de polegada, uma paica são doze pontos. Isso faz com que 1pt seja exatamente 1.3333px e 1cm cerca de 37.8px, sempre, em qualquer aparelho.

Nenhuma delas, porém, é física. Em uma tela com o dobro da densidade de pixels, um pixel do CSS é pintado com quatro pixels de hardware, e no celular o navegador aplica mais uma escala para que o texto continue legível à distância de um braço. width: 1in não mede uma polegada de vidro. Numa folha de estilos de impressão mede, sim, e esse é o único lugar em que pt, cm e mm realmente se justificam.

rem é a preferência de alguém

rem significa o tamanho de fonte computado do elemento raiz html. São 16px porque esse é o tamanho de texto padrão do navegador, e esse padrão é uma preferência que quem lê pode mudar. Para quem definiu 20px porque 16 é difícil de ler, tudo o que você dimensionou em rem fica 25% maior. Tudo o que você dimensionou em pixels continua exatamente tão pequeno quanto era. Esse é todo o argumento a favor do rem em tipografia, espaçamento e media queries, e é um argumento melhor do que o da maioria dos guias de estilo.

Também quer dizer que vale evitar html { font-size: 16px }. Ele sobrescreve a preferência com o seu próprio número e cancela em silêncio o benefício para todo mundo que a mudou.

O truque dos 62.5% e o que ele custa

Definir html { font-size: 62.5% } faz 1rem valer 10px para quem está no padrão, então 1.6rem se lê como "16px" e a conta de cabeça desaparece. Continua proporcional à preferência do usuário, então não é inacessível por si só. O custo é que agora todo tamanho de fonte herdado começa em 10px: você precisa redefinir o body, e qualquer biblioteca de componentes ou folha de estilos de terceiros dimensionada em rem encolhe mais de um terço. Em um projeto que é todo seu, tudo bem. Dentro do design system de outra pessoa, é um vazamento lento.

em acumula, e a exceção que deixa isso confuso

em se refere ao tamanho de fonte do próprio elemento, exceto na propriedade font-size, onde se refere ao do pai. Essa única exceção é o motivo de listas aninhadas em 0.9em irem encolhendo nível a nível, enquanto padding: 1em em um botão se resolve contra o tamanho já escalado daquele mesmo botão. Usado de propósito, é o jeito mais elegante de construir um componente que escala como uma unidade: você define um tamanho de fonte e deixa padding, espaçamentos e raios acompanharem, todos escritos em em. Usado sem querer, é onde se vai uma hora.

Porcentagem significa uma coisa diferente em cada propriedade

Não existe uma referência única para %. A largura se resolve contra a largura do bloco contêiner. A altura se resolve contra a altura dele, e só se essa altura for definida — o que explica por que height: 100% tantas vezes não faz nada. A que surpreende: as porcentagens de padding e margin se resolvem contra a largura do bloco contêiner, incluindo padding-top e margin-bottom. Esse é o mecanismo em que o antigo truque de proporção padding-top: 56.25% se apoiava, antes de aspect-ratio existir. A tabela acima trata % como porcentagem do tamanho de fonte, que é o que ela significa em font-size e line-height.

As unidades de viewport e seus dois bugs famosos

1vw é um por cento da largura da viewport, e nos navegadores de desktop com barras de rolagem clássicas essa largura inclui a barra. Coloque width: 100vw em uma página que rola na vertical e você ganha uma barra de rolagem horizontal de brinde. No celular o problema era a altura: 100vh era medida com a barra de endereços escondida, então uma seção de altura cheia ficava cortada embaixo. svh, lvh e dvh existem para isso, medindo a viewport pequena, a grande e a dinâmica respectivamente. dvh é a que acompanha a barra enquanto ela se esconde, o que também significa que ela pode deslocar o layout enquanto você rola.

Onde este conversor para

px, rem, pt, as unidades físicas e as de viewport são exatas assim que você fornece os quatro números. em e % não são: o valor real depende de onde o elemento está na cascata, e nenhum conversor consegue ler para você o tamanho de fonte computado do pai; a resposta é tão certa quanto o número que você digitou. ch e ex faltam de propósito, porque dependem das métricas dos glifos da fonte real (a largura de avanço do "0" e a altura do x), que mudam a cada arquivo de fonte e não podem ser deduzidas por aritmética. E os números da viewport são lidos desta janela, o que não diz nada de útil sobre o celular de quem visita.

Última atualização 19 de setembro de 2026