Por que ninguém consegue combinar cores sem sofrer
Você já tentou fazer um projeto usando apenas os nomes das cores do CSS? “Coral” não tem nada a ver com “Salmão”, mesmo que pareçam iguais na tela. A tabela de cores com nomes que você vai encontrar na internet geralmente é só uma lista bonita. É inútil se você precisa saber exatamente qual código hexadecimal usar, ou se precisa garantir contraste para acessibilidade. Eu passei dois anos tentando convencer colegas de que nomes de cores são uma porta aberta para inconsistência antes de entender como usá-los sem dor de cabeça. A coisa mais importante que você precisa saber é que nomes de cores existem em duas realidades completamente diferentes. O padrão CSS, que todo navegador entende, tem exatamente 148 nomes definidos. O X11, que veio dos sistemas Unix antigos, tem 680 nomes. Eles se sobrepõem, mas nem sempre coincidem. “Hotpink” no CSS é #FF69B4. No X11, também. Mas “Palegreen” no CSS é #98FB98, enquanto no X11 pode variar dependendo da fonte. Se você copiar uma tabela da Wikipedia e usar os valores do X11 num site CSS, as cores vão piscar diferente do que você esperava. A divergência entre as especificações é mais frequente do que ninguém admite.
A tabela de cores com nomes que eu realmente uso
Não vou enfiar um link genérico. O que funciona de verdade é consultar a especificação oficial do W3C para o CSS Color Module Level 4, que mantém os 148 nomes padronizados com seus valores hexadecimais fixos. Existe também o padrão SVG 1.1, que usa o mesmo conjunto. Se você precisa de mais nomes, aí entra o X11, mas aí você precisa saber qual fonte está usando. Eu mantenho uma planilha própria com as colunas: nome, valor CSS, valor X11 quando diferente, e a classe de contraste WCAG AA para fundo branco. Isso leva uns 20 minutos para montar uma vez, e economiza horas de debugging depois. Dos 148 nomes CSS, alguns são armadilhas clássicas. “Green” não é a cor que seu cérebro espera. É #008000, um verde meio morto, bem diferente do “Lime” que é #00FF00, totalmente saturado. “Brown” é #A52A2A, um marrom alaranjado que ninguém associa a chocolate. “Gray” e “Grey” são sinônimos perfeitos no CSS, ambos #808080, mas muitos desenvolvedores tratam como cores diferentes por puro hábito. E “Orange” é #FFA500, não o tom vibrante que a maioria dos designers imagina. Esses descompassos acontecem porque os nomes foram padronizados em épocas em que monitores CRT tinham gama distorcida e a precisão não era preocupação.
Como construir sua própria tabela sem perder tempo
O processo que eu recomendo começa com uma consulta direta à especificação, não com um site de terceiros. Abra a página do W3C para CSS Colors, copie a tabela oficial, e coloque no Excel ou Google Sheets. Adicione colunas para o valor hexadecimal, o valor RGB, e um cálculo automático de luminosidade relativa usando a fórmula padrão da WCAG. A fórmula é simples: R sRGB = R/255, depois se R sRGB
= 0,03928 use R sRGB/12,92, senão ((R sRGB + 0,055)/1,055)^2,4. Repita para G e B. Luminosidade = 0,2126*R + 0,7152*G + 0,0722*B. Contraste = (L1 + 0,05)/(L2 + 0,05), onde L1 é o mais claro. Se o resultado for 4,5 ou mais, passa no AA para texto normal. Esse cálculo automático elimina a subjetividade. Eu tinha um problema específico que ninguém me avisou. Quando eu exportava a tabela para um sistema de design interno, as cores “Lightgray” e “Darkgray” vinham com valores que pareciam errados. Descubri que o sistema de design da empresa tinha sobrescrito os valores originais do CSS com definições próprias, provavelmente por engano, durante uma migração de biblioteca. O workaround foi fazer uma validação cruzada manual: peguei cada um dos 148 nomes, comparei o hex do meu sheet com o que o navegador renderizava num arquivo HTML simples, e marquei as discrepâncias. Três nomes tinham valores diferentes. Eu corrigi na fonte e forcei o time de design a usar a especificação oficial, não o que estava no sistema legado. Perdeu-se duas semanas, mas evitou inconsistência visual em produção por anos.
👉 Clique no botão abaixo para saber mais sobre o assunto!
O que a maioria das tabelas erra
A maioria das listas que você acha na internet mistura CSS com X11 sem avisar, coloca nomes que foram descontinuados, ou usa valores arredondados que parecem corretos mas falham em testes de contraste. Tem gente que ainda coloca “Maroon” e “Red” como se fossem a mesma coisa, quando “Maroon” é #800000 e “Red” é #FF0000. A diferença é brutal. Também vejo tabelas que inventam nomes como “Babyblue” ou “Seafoam” como se fossem oficiais. Eles existem em paletas proprietárias, mas não estão no padrão CSS. Se você usar essas cores num projeto que precisa ser compatível com múltiplos navegadores ou sistemas, vai ter trabalhoextra para justificar cada um desses valores. Outro erro frequente é achar que nomes de cores são ferramentas de precisão. Eles são aproximativos. “Crimson” não tem um único valor em todos os contextos. No CSS ele é #DC143C. Em outras especificações, pode variar levemente. Se o seu projeto exige que a cor seja idêntica em impressão, tela e código, nomes não são a resposta certa. Você precisa de valores hexadecimais, LAB, ou XYZ explicitamente definidos. A tabela com nomes serve para comunicação rápida, para designers e desenvolvedores se entendem em reunião. Não serve como fonte única de verdade para produção crítica.
Quando abandonar a tabela de nomes
Existem cenários em que eu simplesmente paro de usar nomes. Se você está trabalhando com branding onde a cor do cliente é definida por um manual institucional, aquele manual quase sempre dá o valor CMYK, HEX, Pantone e às vezes Lab. Usar “Royalblue” nesse contexto é incompetência disfarçada de praticidade. Se o projeto exige acessibilidade rigorosa, como um governo ou plataforma de saúde, você não confia em nomes. Você usa a tabela de contraste WCAG com os valores exatos, e testa com simuladores de daltonismo. Se você está num sistema de design tokenizado, como Figma com variáveis, você define a cor uma vez pelo valor e dá um nome útil, mas o nome é apenas um atalho, não a fonte da verdade. Eu também recomendo abandonar nomes quando a equipe tem dificuldade em interpretar tons médios. Nomes como “Lightgray” soam óbvios, mas “Lightgray” no CSS é #D3D3D3, um cinza claro suave, não o branco-acinzentado que muitas pessoas imaginam. Isso gera Diskussion desnecessária em code review. Nesse caso, é mais produtivo usar nomenclatura baseada em função ou hierarquia, como “surface-primary”, “text-secondary”, ou sistemas como Material Design que já resolvem isso de forma consistente.
Referências que realmente valem a pena
A especificação oficial do W3C para CSS Color Module Level 4 mantém a lista canônica dos 148 nomes. A especificação SVG 1.1 também é relevante, já que usa o mesmo conjunto. Para quem quer os 680 nomes do X11, a referência é o padrão CSS Color Level 3, que ainda aparece em documentações legítimas, embora esteja obsoleto. Existem bibliotecas úteis como a chroma.js para JavaScript, que expõe nomes de forma compatível com o padrão, e packages npm como “color-name” que entregam o mapeamento exato. Eu não confio em repositórios de terceiros que atualizam valores sem referenciar a especificação oficial, porque já vi gente introduzir erros de arredondamento que quebravam contrastes calculados. O que eu faço no dia a dia é manter um único arquivo de referência com os 148 nomes, valores hex, e os cálculos de contraste automatizados. Quando surge dúvida, consulto esse arquivo, não a internet. Se precisar de mais cores, uso ferramentas de geração de paleta baseadas em HSL ou Lab, e aí sim atribuo nomes funcionais, não descritivos. Isso elimina a confusão entre “Skyblue” e “Lightblue”, que no CSS são cores distintas mas parecem iguais para leigos. A tabela de cores com nomes é útil quando você entende exatamente onde ela termina e o que começa depois.
