Formatos de cor em CSS: hex, RGB, HSL, OKLCH — qual usar quando

O CSS moderno suporta quatro notações de cor principais: hex (#FF6600), rgb(),hsl() e o mais novo oklch(). Todos descrevem o mesmo gamut de cores (sRGB por padrão, mais amplo para OKLCH). Diferem em legibilidade humana, facilidade de manipulação e que tipo de mudança de cor parece natural.

Os quatro formatos de relance

Hex: o formato de armazenamento

Hex codifica cada canal RGB como um valor hexadecimal de dois dígitos. #FF6600 significa vermelho 255, verde 102, azul 0 — é um laranja vívido.

Prós: curto, universalmente compreendido, amigável para copiar e colar, funciona em todo contexto CSS.

Contras: opaco para ler (“#7E4F2Bé um tom quente ou frio?”), não é possível ajustar facilmente a luminosidade ou saturação sem converter primeiro.

O CSS moderno suporta hex de 8 dígitos para transparência:#FF6600AA é o laranja acima com 67% de opacidade (AA = 170 / 255).

rgb(): o formato de canal explícito

Mesmos canais que hex, números decimais, alfa opcional. Duas sintaxes coexistem:

• Forma legada com vírgula: rgb(255, 102, 0) ou com alfa rgba(255, 102, 0, 0.67)
• Forma moderna com espaço: rgb(255 102 0) ou com alfa rgb(255 102 0 / 0.67)

Melhor para geração programática: construir cor a partir de saída de algoritmo, mesclar duas cores, calcular contraste de acessibilidade.

hsl(): o formato ajustável por humanos

Três valores: matiz (0-360°), saturação(0-100%), luminosidade (0-100%). Ajustar cada um independentemente parece mais natural do que ajustar canais RGB.

• Matiz: a própria cor. 0 = vermelho, 60 = amarelo, 120 = verde, 180 = ciano, 240 = azul, 300 = magenta.
• Saturação: 0% = cinza, 100% = cor pura.
• Luminosidade: 0% = preto, 50% = matiz puro, 100% = branco.

Melhor para: tokens de design onde você quer uma variante “mesma cor, mais escura” — reduza a luminosidade em 10%, mantenha matiz e saturação. Estados de hover, variantes de tema e gradientes se beneficiam.

A pegadinha: a luminosidade do HSL não rastreia o brilho percebido uniformemente. O amarelo HSL com luminosidade 50% parece muito mais brilhante do que o azul HSL com luminosidade 50%. Para design de cores perceptualmente uniforme, OKLCH é a melhor escolha.

oklch(): o formato perceptual

Três valores: L (luminosidade, 0-1),C (croma, 0-~0,4 para sRGB exibível),H (matiz, 0-360°). Baseado no espaço de cor perceptual OKLab (Björn Ottosson, 2020).

A propriedade chave: valores iguais de luminosidade parecem igualmente brilhantes. oklch(0.6 0.2 0) (vermelho) e oklch(0.6 0.2 120) (verde) eoklch(0.6 0.2 240) (azul) têm todos o mesmo brilho percebido, ao contrário do HSL onde esses valores variariam dramaticamente.

Melhor para: projetar escalas de cores, temas de modo escuro, garantindo que o contraste de texto se mantenha ao longo de uma rotação de matiz. Suportado em todos os navegadores evergreen desde 2023.

A pegadinha: o croma atinge o máximo em valores diferentes por matiz. O azul de alto croma é alcançável; o amarelo de alto croma atinge os limites do gamut sRGB mais cedo. Use um valor de croma que o navegador possa renderizar em todo matiz que você precisar, ou aceite o recorte nos extremos.

Escolhendo o certo

• Para cores de marca e tokens de design:defina em HSL ou OKLCH; é o que os designers podem ajustar de forma significativa. Armazene hex como fallback em arquivos legados.
• Para ramificações de cor de UI (50/100/200/.../900):OKLCH com croma fixo e luminosidade variável produz escalas perceptualmente uniformes. HSL funciona, mas o espaçamento visual é irregular.
• Para copiar de uma especificação do Figma/Photoshop:cole hex. Converta via nossa ferramenta hex para RGB ou um pré-processador CSS quando precisar manipular.
• Para escolhas orientadas a acessibilidade: calcule o contraste WCAG no formato rgb. A fórmula de contraste opera em RGB linear, não em hex ou HSL diretamente.

O padrão de propriedade personalizada CSS

Arquiteturas de tema modernas armazenam cores como propriedades personalizadas HSL/OKLCH para que possam ser derivadas:

:root {
  --primary-hue: 24;
  --primary: oklch(0.72 0.18 var(--primary-hue));
  --primary-hover: oklch(0.65 0.18 var(--primary-hue));
  --primary-bg: oklch(0.92 0.05 var(--primary-hue));
}

Alterar o matiz uma vez rotaciona toda a paleta de forma consistente. O mesmo padrão com hex é impossível sem funções de pré-processador.

A conclusão

Hex para armazenamento e cópia e cola. RGB para programático. HSL para ajuste de designer. OKLCH para ramificações perceptualmente uniformes. A especificação CSS permite misturar livremente; escolha o formato que corresponde ao que você está fazendo com a cor.

Fontes: CSS Color Module Level 4 (W3C); Björn Ottosson,Um espaço de cor perceptual (2020); documentação MDN sobre funções de cor CSS modernas.

Exemplo prático: construindo uma ramificação de 10 passos de cor de UI

Uma ramificação de sistema de design geralmente vai de 50 / 100 / 200 / 300 / 400 / 500 / 600 / 700 / 800 / 900 — do mais claro ao mais escuro — com 500 como a cor de marca “verdadeira”. A questão é como deve ser cada passo intermediário.

Usando HSL com matiz e saturação constantes, variando a luminosidade de 95% (passo 50) a 15% (passo 900):

--brand-50:  hsl(24 100% 95%);
--brand-100: hsl(24 100% 90%);
--brand-200: hsl(24 100% 80%);
--brand-300: hsl(24 100% 70%);
--brand-400: hsl(24 100% 60%);
--brand-500: hsl(24 100% 50%);  /* base */
--brand-600: hsl(24 100% 42%);
--brand-700: hsl(24 100% 34%);
--brand-800: hsl(24 100% 26%);
--brand-900: hsl(24 100% 18%);

Problema: a luminosidade HSL é matematicamente uniforme mas perceptualmente não. O salto de brand-400 para brand-500 parece dramático; o salto de brand-800 para brand-900 é quase imperceptível. A ramificação parece irregular.

OKLCH com croma constante, variando a luminosidade de 0,97 a 0,20:

--brand-50:  oklch(0.97 0.04 47);
--brand-100: oklch(0.93 0.07 47);
--brand-200: oklch(0.86 0.11 47);
--brand-300: oklch(0.78 0.15 47);
--brand-400: oklch(0.71 0.18 47);
--brand-500: oklch(0.64 0.21 47);  /* base */
--brand-600: oklch(0.55 0.20 47);
--brand-700: oklch(0.46 0.17 47);
--brand-800: oklch(0.36 0.13 47);
--brand-900: oklch(0.26 0.09 47);

Cada passo parece um passo perceptualmente uniforme do anterior. O croma diminui na extremidade escura porque cores de alto croma simplesmente não existem em baixa luminosidade no sRGB — física, não uma escolha de ferramental. Tailwind v4, Radix Colors v3 e a maioria dos sistemas de design modernos migraram para ramificações OKLCH após 2023 exatamente por esse motivo.

Erros comuns ao escolher um formato de cor

• Especificar transparência de duas formas diferentes de forma inconsistente. rgba(255 102 0 / 0.67) e #FF6600AB são a mesma cor, mas ter ambos em uma stylesheet torna busca e substituição e tematização frágeis. Escolha uma notação por projeto.
• Confiar no OKLCH em croma extremo. oklch(0.6 0.4 47) solicita um croma que o gamut de exibição sRGB não pode renderizar; o navegador recorta para o valor renderizável mais próximo. Verifique se a intenção do seu design é renderizada corretamente em displays reais, ou restrinja o croma ao intervalo sRGB seguro (máx ~0,25 para matizes quentes, ~0,15 para amarelo-verde).
• Calcular contraste WCAG em valores HSL ou OKLCH.A fórmula de contraste WCAG 2.1 opera em sRGB de luz linear. Ferramentas que recebem entradas HSL ou OKLCH convertem internamente para sRGB primeiro; calcular a fórmula manualmente requer a conversão. APCA (a métrica de contraste do rascunho WCAG 3) lida com uniformidade perceptual nativamente e vale investigar para novos projetos.
• Codificar hex em componentes. color: #FF6600 dentro de um componente bloqueia a cor a um valor; a troca de tema torna-se um exercício de busca e substituição. Sempre referencie propriedades personalizadas (var(--brand-500)) definidas na raiz, não valores hex literais.
• Usar color: red ou outras cores nomeadas.As cores nomeadas CSS (red =#FF0000, orange =#FFA500) são tecnicamente suportadas, mas têm cores primárias sRGB extravagantes e não projetadas que raramente correspondem a uma paleta de marca. Trate-as como cores de depuração, não de produção.

Quando a escolha do formato de cor CSS NÃO importa

• Páginas estáticas únicas sem tematização. Uma landing page com 5 cores e sem modo escuro: use hex e siga em frente. As vantagens do OKLCH só valem a pena quando você está gerando ramificações ou suportando múltiplos temas.
• Saída voltada para impressão. Qualquer coisa destinada à impressão CMYK precisa ser convertida de sRGB por um perfil ICC para o espaço de cor da prensa de destino. A notação CSS é irrelevante; o que importa é o perfil de origem e a intenção de renderização. Veja nossa comparação RGB vs CMYK para os detalhes de gamut e conversão.
• HTML de e-mail. Outlook 2007-2019 e alguns clientes de webmail ainda não suportam funções de cor CSS modernas de forma confiável. Templates de e-mail devem usar hex de 6 dígitos como fallback; OKLCH e hex de 8 dígitos quebram no Outlook para desktop.
• Design de gamut amplo P3 / Display P3 estrito. O espaço de cor Apple Display P3 acessível via color(display-p3 ...) é uma discussão completamente diferente — veja a entrada do glossário P3 e nossa entrada do glossário de gamut para quando a saída de gamut amplo vale a complexidade.

Para os detalhes completos da especificação, o CSS Color Module Level 4 cobre cada notação, e a publicação original do OKLab de Björn Ottosson (2020) é a referência canônica para o modelo perceptual por baixo do OKLCH. Para conversão interativa de formatos, o conversor de cores lida com hex ↔ rgb ↔ hsl ↔ oklch com relatório de contraste WCAG.

Considerações de desempenho

As quatro notações são computacionalmente equivalentes em tempo de renderização — o navegador converte tudo para RGB linear internamente antes de pintar. As diferenças de desempenho entre notações estão dentro do ruído de medição em qualquer dispositivo moderno. O que pode custar desempenho é:

• Uso intenso de color-mix() com argumentos de propriedade personalizada. Cada chamada color-mix() é resolvida em tempo de pintura; usar centenas em um único frame de renderização pode aparecer em auditorias do Lighthouse. Pré-calcule misturas em tempo de build para paletas estáticas.
• Gamut amplo color(display-p3 ...) em dispositivos sem displays P3. O navegador realiza mapeamento de gamut por elemento. Gratuito em Macs com chip M e iPhones recentes; custo mensurável em hardware Windows mais antigo.
• Fundos semi-transparentes em camadas. A composição do canal alfa é rápida em GPUs modernas, mas lenta em Android de baixo custo. Empilhar 5+ camadas transparentes pode desencadear tempestades de pintura nos 20% inferiores dos dispositivos.

Suporte de navegadores e estratégia de fallback

Suporte de navegadores no início de 2026:

Para e-mail e contextos de navegadores legados, o alvo seguro é hex de 6 dígitos mais soluções separadas para canal alfa (fallbacks de PNG semi-transparentes). Para a web moderna, OKLCH é totalmente utilizável; o raro navegador desatualizado provavelmente também está falhando em recursos mais importantes e merece uma estratégia separada em vez de compromissos de cores.

A regra at-rule CSS @supports permite aprimoramento progressivo: defina um fallback hex primeiro, depois um override OKLCH dentro de @supports (color: oklch(0 0 0)) para navegadores que suportam a nova sintaxe. Na prática, poucos sites se incomodam — o grupo com suporte OKLCH agora representa mais de 96% do tráfego global de navegadores segundo dados do Can I Use, e a diferença visual entre uma ramificação OKLCH e um fallback HSL é pequena o suficiente para que a estratégia mais simples seja usar um conjunto de valores e aceitar os 3-4% que verão uma aproximação HSL.