Conversor de unidades CSS
Converta entre px, rem, em, vw, vh, pt, cm, mm, in e % com um contexto configurável.
Configurações de contexto
Converter
Resultados
Referência das unidades CSS
Unidades absolutas
- px · pixels (1/96 de polegada)
- pt · pontos (1/72 de polegada)
- cm · centímetros
- mm · milímetros
- in · polegadas
Unidades relativas
- rem · relativo ao tamanho da fonte raiz
- em · relativo ao tamanho da fonte pai
- vw · 1 % da largura da viewport
- vh · 1 % da altura da viewport
- vmin · 1 % da menor dimensão da viewport
- vmax · 1 % da maior dimensão da viewport
- % · porcentagem do elemento pai
Quando usar rem ou em ?
Use rem para um dimensionamento consistente (margens, padding, tamanhos de fonte) · sempre se refere à raiz. Use em quando quiser um dimensionamento relativo ao pai, como componentes aninhados que se adaptam ao seu contexto.
Por que px nem sempre é igual a um pixel físico ?
O px CSS é um « pixel de referência » definido como 1/96 de polegada à distância do braço. Em telas de alta densidade (HiDPI), um px CSS pode corresponder a 2 ou 3 pixels físicos.
O pixel de referência do CSS, a pedra angular de toda unidade absoluta
As unidades absolutas do CSS (in, cm, mm, Q, pt, pc, px) estão ancoradas no pixel de referência do CSS. O CSS Values and Units Module Level 3 do W3C o define como «o ângulo visual de um pixel em um dispositivo com densidade de pixels de 96 dpi e uma distância de um braço de comprimento até o leitor». Para um braço de cerca de 28 polegadas, esse ângulo visual é de aproximadamente 0,0213°, equivalente a cerca de 0,26 mm de largura física de tela na distância de visualização típica, e a especificação ilustra que o mesmo ângulo visual se traduz em cerca de 1,3 mm a 12 pés, e é por isso que os pixels de projetores e TVs podem ser fisicamente maiores, mas ainda contam como um pixel CSS cada.
Para telas, a especificação define em CSS 1in = 96 px, em vez de derivar de polegadas reais da tela. Isso significa que as conversões na tabela acima são exatas e não dependem do DPI do monitor: 12 pt são sempre 16 px, 1 pc é sempre 16 px, 1 mm é sempre cerca de 3,78 px. Em um monitor de alto DPI (Retina, 4K), o sistema operacional mapeia cada pixel CSS para os pixels de dispositivo que melhor aproximam o ângulo visual, normalmente 2 pixels de dispositivo por pixel CSS em um MacBook Retina, 3 em um iPhone Pro, 1,5 em um desktop Windows com escala de 150%. Uma borda 1px nítida em uma tela Retina ocupa 2 pixels de dispositivo.
Unidades relativas à fonte
Estas se resolvem em relação à tipografia, e não a polegadas físicas. Elas são a base de layouts acessíveis e escaláveis.
O em é a pedra fundamental, com uma profundidade histórica surpreendente: ele antecede o CSS em cerca de 500 anos. Na impressão com tipos móveis (pós-Gutenberg, por volta de 1450), o «em quad» era um bloco quadrado de metal cuja largura igualava a altura do corpo do tipo, aproximando historicamente a largura do M maiúsculo. O CSS toma emprestada a abstração: 1em equivale ao font-size computado do elemento atual. A famosa pegadinha é que declarações font-size: 1.2em aninhadas se multiplicam: um filho de 1.2em dentro de um pai de 1.2em é renderizado em 1,44× o avô.
O rem («root em», em da raiz) foi adicionado no CSS3 para resolver exatamente esse problema de acúmulo. 1rem equivale ao font-size do elemento raiz <html>, sem ser afetado pelo aninhamento de pais. Os navegadores adotam por padrão 16 px na raiz, a menos que o usuário substitua isso, então 1rem = 16px nas condições padrão. O rem chegou no Safari 4.1 e no Firefox 3.6 em 2010, no IE9 em março de 2011; o IE8 nunca o suportou, o que forçou fallbacks em px até por volta de 2014.
Unidades mais novas relativas à fonte (CSS Values 4) incluem ch (a largura do caractere «0» na fonte atual, útil para larguras máximas de comprimento de linha como max-width: 60ch ou 66ch, que ficam na faixa de leitura tipograficamente ideal de 45-75 caracteres), ex (a altura de x da fonte), cap (a altura das maiúsculas), ic (o avanço do ideograma CJK 水) e lh / rlh (o line-height computado do elemento / da raiz, útil para o ritmo vertical).
Unidades de porcentagem da viewport (e o problema da barra de endereços no celular)
Os quatro clássicos, vw, vh, vmin, vmax, representam 1% da largura da viewport, 1% da altura da viewport, 1% do menor dos dois e 1% do maior. Em 1920 × 1080: 1vw = 19.2px, 1vh = 10.8px.
O 100vh foi por muito tempo uma dor de cabeça no celular, porque tanto o iOS Safari quanto o Chrome Mobile mostram uma barra de URL que se retrai à medida que você rola. Os navegadores tiveram de escolher: fazer 100vh igual à viewport curta (barra de URL visível, o conteúdo fica cortado depois da rolagem) ou à alta (barra de URL oculta, grande espaço vazio na pintura inicial). O iOS Safari escolheu o comportamento alto, deixando os desenvolvedores depurando «por que minha seção de destaque está mais alta que a tela?» por anos.
O esforço Interop 2022 (Apple, Google, Igalia, Microsoft, Mozilla e outros) adicionou novas variantes de viewport em março de 2022 para corrigir isso:
- Viewport pequena (
svw/svh/svmin/svmax), assume que a interface do navegador está totalmente expandida; a menor viewport possível. Estável na pintura inicial. - Viewport grande (
lvw/lvh/ etc.), assume que a interface do navegador está totalmente retraída; a maior viewport possível. - Viewport dinâmica (
dvw/dvh/ etc.), atualiza em tempo real conforme a interface encolhe e expande. O melhor encaixe, mas pode causar repinturas durante a rolagem.
Receita prática: min-height: 100svh em uma seção de destaque para que ela não corte no iOS, ou height: 100dvh em um modal de tela cheia. O Safari lançou o suporte primeiro (15.4, março de 2022); o Firefox 101 (maio de 2022); o Chrome e o Edge 108 (dezembro de 2022). O suporte global hoje é amplo.
Unidades de container query
Uma família mais nova, cqw, cqh, cqi, cqb, cqmin, cqmax, permite que um elemento se dimensione com base em seu container, e não na viewport. Essencial para o design orientado a componentes, em que o mesmo componente pode aparecer com 300 px de largura em uma barra lateral e 900 px em uma coluna principal. A unidade é avaliada em relação ao container ancestral mais próximo que tenha container-type definido; se não existir nenhum container elegível, a especificação recorre à unidade de viewport pequena naquele eixo. As container queries (e as unidades) chegaram no Chromium 105 em 2022, no Safari 16 em setembro de 2022 e no Firefox 110 em fevereiro de 2023, tornando-se Baseline recém-disponível em 2023.
Porcentagens, e por que elas não são realmente um comprimento
As porcentagens não são uma unidade de comprimento em si, são um tipo de valor separado que se resolve conforme o contexto:
- Em
width/height: porcentagem do tamanho inline / block do pai. - Em
font-size: porcentagem do font-size computado do pai. - Em
line-height: porcentagem do próprio font-size do elemento. - Em
marginepaddingnos quatro lados: porcentagem do tamanho inline do pai (ou seja, a largura). Essa é a origem da famosa surpresa de que «a margem vertical em % é igual à horizontal». - Em
transform: translate(): porcentagem das próprias dimensões do elemento.
Por causa dessa resolução contextual, % não pode simplesmente ser convertido em px sem conhecer a dimensão do pai; o conversor acima a pede explicitamente.
Orientação prática: quando usar o quê
- Use rem para
font-size. Ele respeita a configuração de fonte padrão do navegador do usuário, um ganho real de acessibilidade, porque os usuários com deficiência visual podem escalar globalmente, em vez de site por site. - Use em para proporções internas de componentes: tamanhos de ícone que devem combinar com o texto do botão, padding dentro de um botão que escala com o texto.
- Evite px em
font-size. O zoom do navegador ajuda, mas só site por site; o rem também respeita a substituição do tamanho de fonte padrão do usuário. - px serve para bordas, elementos decorativos nítidos e sombras, em que a espessura física importa mais do que a escala.
- % para layouts fluidos, em que os filhos devem preencher o pai.
- vw / vh para seções de destaque, fundos de sangria total e modais: mas recorra a
svhoudvhem vez devhem qualquer coisa que encoste na parte de baixo das telas de celular. - vmin para elementos de proporção quadrada (avatares, telas de abertura) para que caibam nos dois eixos.
- ch para larguras máximas de comprimento de linha em texto corrido:
max-width: 60chou66chfica na faixa de leitura ideal.
Tipografia fluida com clamp()
clamp(MIN, PREFERRED, MAX) retorna o valor preferido limitado pelo piso e pelo teto. O padrão clássico de tipografia fluida combina um piso e um teto em rem com um meio de escala guiado por vw:
h1 { font-size: clamp(1.8rem, 1.2rem + 2.5vw, 3rem); }
O termo do meio escala linearmente com a viewport, enquanto o piso e o teto baseados em rem evitam tamanhos extremos e preservam a escala de fonte do usuário. O clamp() alcançou o Baseline amplamente disponível em julho de 2020 (Chrome 79, Firefox 75, Safari 13.1). Ferramentas como o Utopia (utopia.fyi) e o fluid-type-scale.com recebem larguras mín / máx de viewport, tamanhos mín / máx de fonte e uma razão de escala modular (1,2, 1,25, 1,333, 1,5, áurea) e emitem declarações prontas para colar.
Acessibilidade, WCAG SC 1.4.4 Redimensionar Texto
O padrão exige que o texto possa ser ampliado para 200% do tamanho original sem perda de conteúdo ou funcionalidade. Ele não impõe uma unidade específica, mas as técnicas suficientes listadas incluem «usar medidas que sejam relativas a outras medidas no conteúdo»; as unidades relativas (em, rem, %) facilitam a conformidade; layouts apenas em pixel podem passar via zoom do navegador, mas são mais frágeis. O teste mental: isto deveria escalar quando o usuário aumenta o tamanho padrão do texto? Se sim, use rem. Bordas, padding decorativo e decoração pura podem ficar em px.
Mais perguntas
Por que 1in não é realmente uma polegada na minha tela?
Porque a especificação do CSS ancora as unidades absolutas em uma referência de ângulo visual, e não em polegadas físicas. Um 1in do CSS é definido como exatamente 96 pixels CSS, que o navegador mapeia para os pixels de dispositivo que melhor aproximam a referência na distância de visualização típica. Na maioria dos monitores, isso acaba próximo de uma polegada real, mas em uma TV vista do outro lado da sala será fisicamente maior, e em um laptop de alto DPI no seu colo pode ser ligeiramente menor. Para uma medição física real, use uma régua contra a tela.
O que é o «truque dos 62,5%» que às vezes mencionam?
Um padrão muito usado: html { font-size: 62.5%; }. Como 62,5% × 16 = 10, isso faz 1rem = 10px: conveniente para a conta de cabeça (1.6rem = 16px, 2.4rem = 24px). É controverso; os opositores argumentam que ele substitui o tamanho de fonte padrão preferido do usuário e é levemente hostil ao usuário em termos de acessibilidade. Muitas equipes modernas escolhem uma razão com a substituição do usuário explicitamente preservada (por exemplo, definindo o font-size do body em rem, para que a cascata respeite o padrão do usuário).
Quando devo usar vw vs. cqw?
Use vw quando o tamanho deve acompanhar a viewport (texto de destaque de sangria total, modais de tela cheia). Use cqw quando o tamanho deve acompanhar o container do componente: por exemplo, um título de card que fica maior quando o card está na coluna principal e menor quando está em uma barra lateral, independentemente do tamanho da viewport. As unidades de container query chegaram em 2022-2023 e são a resposta certa quase sempre que, de outra forma, você recorreria a uma escala de fonte guiada por media query em um único componente.
Qual é a diferença entre dpi e dppx nas @media queries?
Ambos expressam resolução. dppx significa «pontos por pixel CSS», 1dppx = 96dpi, já que o CSS define 96 px por polegada. @media (min-resolution: 2dppx) tem como alvo os monitores de classe Retina, em que cada pixel CSS é renderizado com pelo menos 2 pixels de dispositivo. Usar dppx é geralmente preferível, porque evita a confusão entre dpi e polegada CSS.
Algo é enviado a um servidor?
Não. As conversões são aritmética simples de JavaScript rodando localmente no seu navegador. Nada sobre as suas entradas é enviado a lugar nenhum; a página funciona offline depois de carregada.