Formatador e embelezador CSS gratuito

O que a formatação de CSS realmente faz

Um formatador de CSS (também chamado de «beautifier» ou «pretty-printer») pega CSS em qualquer forma, saída de produção minificada, fragmentos de uma só linha colados a partir do inspetor do navegador, folhas de estilos escritas à mão com indentação inconsistente, e devolve-o com indentação convencional, quebras de linha e formatação consistente de selectores e declarações. O parser de CSS do navegador ignora os espaços em branco no momento do parsing, pelo que a página renderizada fica idêntica independentemente de como a fonte está disposta. A questão é puramente a legibilidade humana: a hierarquia indentada torna visível a aninhamento de @media, uma propriedade por linha permite que os teus olhos varrem rapidamente as declarações de uma regra, e a formatação consistente em todo um codebase acelera a revisão de diffs. Os quatro fluxos do mundo real: (1) depurar CSS minificado de produção colado do Inspetor das DevTools para perceber por que uma regra não está a aplicar; (2) reformatar CSS extraído do painel «Computed» de um navegador para comparar com a fonte; (3) normalizar diferenças de formatação da equipa depois de um merge de um colaborador que usa outras convenções; (4) preparar CSS para revisão de código quando a fonte se degradou em linhas compactas.

Os principais formatadores de CSS

js-beautify (Einar Lielmanis, desde 2007) é o formatador histórico do ecossistema JavaScript, a sua metade CSS é o que alimenta a fachada pública do beautifier.io e historicamente apoiou dezenas de sites «format CSS online». Prettier (James Long, janeiro de 2017; suporte CSS adicionado na v1.4 a 3 de junho de 2017) é o formatador opinionated que veio a dominar o ecossistema frontend moderno. A filosofia de design do Prettier é «quase sem configuração», um único estilo de indentação (2 espaços por defeito), um único alvo de largura de linha, quebra de linha previsível. É o formatador por defeito para CSS no VS Code quando a extensão Prettier está instalada. Stylelint (David Clark + Maxime Thirouin, 2015) é mais um linter do que um formatador, mas suporta format-on-save através da flag --fix e é a escolha de facto para impor convenções CSS numa equipa, as suas mais de 100 regras embutidas cobrem tudo desde «sem selectores duplicados» até «preferir hex sobre rgb()» passando por «só aspas simples». clean-css (Jakub Pawlowicz, 2011) minifica principalmente, mas tem um modo «beautify» que inverte a operação. Os quatro acabam por parsear CSS através de PostCSS (Andrey Sitnik, iniciado a 7 de setembro de 2013), o parser de CSS universal que alimenta a maior parte do ecossistema CSS moderno (Autoprefixer, cssnano, o processamento do Tailwind). Para projectos modernos em 2026, Prettier ao guardar é o valor por defeito; esta ferramenta no navegador é para casos pontuais fora de qualquer contexto de projecto.

Convenções de indentação e selectores

As convenções CSS em 2026 inclinam-se fortemente para indentação de 2 espaços, o valor por defeito no Prettier, no código do Tailwind, no Code Guide do Bootstrap, no Google CSS Style Guide e na maioria dos pacotes CSS publicados no npm. A convenção mais antiga de 4 espaços persiste em alguns codebases legados. Tabulações são raras especificamente em CSS (mais comuns em JS/TS). Para os selectores: listas de selectores separados por vírgula são convencionalmente escritas um por linha (.btn,<br>.btn-primary,<br>.btn-secondary {), o que torna fácil acrescentar ou retirar um selector sem reordenar a linha. Os combinadores (>, +, ~) costumam ter um espaço de cada lado. As cadeias de pseudoclasses (:hover:focus) ficam coladas. Os selectores universais (*) e os combinadores de descendência (o espaço implícito) são neutros para o formatador.

Formatação de declarações

Uma declaração por linha é o valor por defeito moderno, color: red; na sua própria linha, padding: 10px; na seguinte. A alternativa «compacta» (várias declarações numa só linha) é rara no CSS de produção hoje em dia; a maioria das equipas passou a uma-por-linha por legibilidade e diffs limpos. Um único espaço a seguir aos dois pontos: color: red; e não color:red;. Ponto e vírgula final na última declaração: tecnicamente opcional pela spec do CSS, mas todo o formatador moderno o inclui pela amabilidade dos diffs, acrescentar uma propriedade nova não exige modificar a linha anterior. Linha em branco entre regras: opcional e dependente da equipa. O Prettier preserva as linhas em branco da entrada em vez de impor um estilo específico. Aspas em propriedades: nomes de fontes com espaços exigem aspas (font-family: "Helvetica Neue", sans-serif;); as URLs vêm convencionalmente entre aspas (url("image.png")) embora sem aspas seja válido. Normalização de valores: palavras-chave em minúsculas (RED → red), abreviatura hex (#FFFFFF → #fff), remoção de unidade zero (0px → 0), a maior parte destas pertence a um minificador e não a um formatador, mas alguns formatadores aplicam as que são sem perdas.

Casos especiais de CSS

As media queries aninham as suas regras com um nível extra de indentação, tornando visualmente óbvia a estrutura condicional. Os blocos @keyframes contêm regras em percentagem (0% { ... }, 100% { ... }) que aninham da mesma forma. As declarações @font-face têm vários pares src/format que beneficiam de ficar um por linha. As propriedades CSS personalizadas (--brand-color: #3b82f6;) são formatadas como qualquer outra declaração, mas o nome da propriedade preserva a caixa (os nomes de propriedades personalizadas são sensíveis a maiúsculas/minúsculas, ao contrário das propriedades padrão). As expressões calc() exigem espaços à volta dos operadores, calc(100% - 20px) está correcto, calc(100%-20px) é CSS inválido. Os formatadores preservam os espaços necessários dentro de calc() enquanto normalizam o contexto à volta. CSS Nesting (CSS Nesting Module Level 1, baseline 2023+) (uma funcionalidade relativamente nova que permite que regras aninhadas indentem sob a sua mãe) mudou a forma como os formatadores tratam a sintaxe aninhada; o Prettier moderno e o Stylelint compreendem ambos a sintaxe nativa.

Ordenar propriedades, uma convenção surpreendentemente disputada

Algumas equipas impõem uma ordem de propriedades dentro de cada regra. Três convenções competem. Alfabética (a opção «Ordenar propriedades» desta ferramenta): a mais simples, fácil de impor mecanicamente, transforma «esta propriedade já está declarada aqui?» numa varredura rápida. O Google CSS Style Guide recomenda alfabética com concessões para os prefixos de fornecedor. Por conceito (posicionamento → modelo de caixa → tipografia → visual → animação): agrupa propriedades relacionadas. O livro de arquitectura SMACSS popularizou esta abordagem. Por tipo (display primeiro, depois modelo de caixa, depois texto, depois diversos): variante do «por conceito» com agrupamentos mais rígidos. A regra order/properties-order do Stylelint suporta qualquer destas via configuração. Nenhuma das três melhora a renderização; a escolha depende puramente do modelo mental que achas mais fácil ao varrer uma regra. Esta ferramenta oferece a ordenação alfabética como toggle opcional; para as outras convenções precisarias de um ficheiro de configuração do Stylelint num projeto real.

O pipeline moderno de CSS

Para projetos com pipeline de build, o valor por defeito em 2026 é o Prettier a correr ao guardar no teu editor e o Stylelint em cada commit via Husky + lint-staged. VS Code traz o Prettier como formatador por defeito para ficheiros CSS, SCSS e LESS quando a extensão está instalada. Os hooks pre-commit via Husky executam o Stylelint e o Prettier sobre os ficheiros em stage antes de permitir o commit. As verificações de CI correm stylelint --check e prettier --check em pull requests. Depois da formatação em desenvolvimento, o CSS de produção passa pelo cssnano (baseado em PostCSS, o padrão moderno de minificação), que inverte tudo o que o formatador fez para produzir bytes comprimidos prontos a entregar. Nada disto importa para fragmentos pontuais colados de outro lado, é exactamente para isso que esta ferramenta no navegador serve. Para o trabalho de projecto a longo prazo, configura Prettier + Stylelint localmente; a ferramenta no navegador é a opção sem fricção para tudo o resto.

Casos de uso comuns

• Revisão de código. Tornar legível CSS minificado ou compacto antes de o partilhar com um colega.
• Depuração. CSS bem formatado torna instantaneamente visível que selectores estão a aplicar e que declarações estão a ser sobrescritas.
• Refactorização. Compreender a estrutura de uma folha de estilos que não escreveste é muito mais fácil com formatação consistente.
• Limpeza a partir do inspetor do navegador. O botão «Copiar regra» das DevTools produz CSS compacto e difícil de ler; formata-o antes de o colares na tua folha de estilos.
• Minificação de produção. O toggle «Modo minify» inverte a formatação, útil para implementar CSS em produção onde cada byte importa.
• Padronização de equipa. Adequar às convenções de formatação da equipa antes de submeter um PR.

Privacidade: porque é que «só no navegador» importa aqui

O CSS raramente contém segredos explícitos, mas as folhas de estilos proprietárias revelam informação sobre a taxonomia interna de classes do site, tokens de design system, hipóteses de testes A/B codificadas em nomes de selectores e funcionalidades não entregues. Os formatadores do lado do servidor enviam o teu CSS para um serviço de terceiros onde fica em registos. Esta ferramenta corre inteiramente no teu navegador via JavaScript, verifica no separador Rede das DevTools enquanto carregas em Formatar, ou põe a página offline (modo de avião) depois de carregada e o formatador continua a funcionar. Seguro para folhas de estilos proprietárias, ficheiros source-of-truth de design systems, variantes de testes A/B, ou qualquer CSS que não queiras ver copiado para o disco rígido de um estranho.

Perguntas frequentes

O que é a beautificação de CSS?

Beautificação (também «formatação» ou «pretty-printing») reformata o código fonte CSS para o tornar mais legível, adicionando indentação adequada, quebras de linha entre regras, declarações com uma propriedade por linha, espaçamento consistente à volta dos dois pontos. A saída renderizada pelo navegador é idêntica porque o parser de CSS ignora os espaços em branco no momento do parsing. O objectivo é a legibilidade humana para revisão de código, depuração e edição, não uma alteração na aparência da página.

Quando devo usar CSS minificado?

O CSS minificado retira todo o espaço em branco desnecessário e é a escolha certa para implementação em produção, reduz o tamanho do ficheiro entre 20 e 40 % antes da compressão Brotli no edge da CDN, e cada byte tirado do caminho de renderização crítico importa para os Core Web Vitals (em especial LCP). O CSS embelezado é para desenvolvimento, revisão de código e depuração. Os pipelines de build modernos (Vite, webpack, Parcel, Astro, Next.js) minificam automaticamente em builds de produção via cssnano ou Lightning CSS, pelo que para trabalho de projeto tipicamente escreves CSS embelezado e o teu bundler emite a versão minificada.

O que faz «ordenar propriedades alfabeticamente»?

Ordena alfabeticamente as declarações dentro de cada regra, border antes de color antes de display antes de margin. Algumas equipas impõem a ordem alfabética porque transforma «X já está declarada aqui?» numa varredura rápida e evita discussões sobre propriedades duplicadas em revisão de código. O Google CSS Style Guide recomenda alfabética (com concessões para os prefixos de fornecedor). Outras equipas preferem ordem «por conceito» (posicionamento → modelo de caixa → tipografia → visual → animação, popularizada pelo SMACSS). Nenhuma das ordenações afecta a renderização, escolha puramente cosmética / convenção de equipa.

O que faz «uma propriedade por linha»?

Coloca cada declaração na sua própria linha, color: red; numa linha, padding: 10px; na seguinte, em vez de as agrupar numa só linha. O valor por defeito moderno em essencialmente todo o CSS de produção, porque torna os diffs mais limpos (adicionar uma propriedade = adicionar uma linha, não modificar uma) e torna cada declaração mais fácil de ler individualmente. O oposto (várias declarações por linha) é raro no código de produção em 2026 fora de fragmentos muito compactos de uma só regra.

Devo usá-la se o meu projeto já usa Prettier ou Stylelint?

Provavelmente não, a integração do Prettier no teu editor está a fazer isto ao guardar, com plena consciência da AST de CSS via PostCSS, e o Stylelint impõe convenções de equipa em cada commit. Esta ferramenta é para os casos que o teu pipeline de build não cobre: CSS colado a partir do inspetor do navegador, fragmentos de e-mail ou Stack Overflow, formatação pontual fora de qualquer contexto de projeto. Para trabalho de projeto a longo prazo, configura Prettier + Stylelint localmente; para trabalho pontual sem fricção, esta ferramenta é a forma certa.

Os meus ficheiros CSS são enviados?

Não. A formatação corre inteiramente no teu navegador via JavaScript. O CSS que colas nunca atravessa a rede, verifica no separador Rede das DevTools enquanto carregas em Formatar, ou põe a página offline (modo de avião) depois de carregada e a ferramenta continua a funcionar. Seguro para folhas de estilos proprietárias, ficheiros source-of-truth de design systems, variantes de testes A/B ou qualquer CSS que não queiras ver copiado para o disco rígido de um estranho.

Ferramentas relacionadas