Pular para a ferramenta
makeshortwork.com Formatador de HTML

Formatador e Minificador de HTML

Cole o HTML e receba tudo indentado e legível — ou minificado de volta. Seguro com espaço em branco: o conteúdo de pre, textarea, code e script nunca é alterado. Nada é enviado.

 

Espaço em branco é conteúdo em HTML

Indentar JSON é tarefa mecânica. Indentar HTML não é, porque HTML é o formato raro em que o espaço em branco às vezes desaparece e às vezes vira um espaço visível na tela — e a regra de qual é qual depende do elemento, do contexto e do CSS aplicado. Um formatador que ignora isso entrega um arquivo mais bonito e uma página diferente. O estrago costuma ser discreto o suficiente para passar no code review e ir para produção.

O exemplo cabe em duas linhas. Escreva <a>um</a><a>dois</a> e os dois links ficam grudados, sem nada entre eles. Coloque uma quebra de linha entre as tags para ficar mais legível e o navegador transforma essa quebra em um espaço: agora os links estão separados. Nada no código avisa. O mesmo acontece com <strong>10</strong><span>%</span>, com o separador de um breadcrumb, com botão de ícone mais texto e com todo preço montado a partir de dois spans.

Por isso a regra desta ferramenta é estreita e mecânica: uma quebra de linha só pode substituir um espaço que já existia, ou acontecer na borda de uma caixa de bloco, onde o algoritmo de linha do CSS remove o espaço do começo e do fim de qualquer jeito. Onde dois elementos inline se tocam, eles continuam se tocando — mesmo que isso deixe a linha bem além da largura escolhida. Linha comprida é problema estético. Espaço que apareceu do nada é bug de renderização.

Tem ainda uma armadilha que derruba formatador feito com expressão regular: em JavaScript, \s casa com U+00A0, que é o caractere que o &nbsp; produz. Esse caractere existe justamente porque ele não colapsa. Formatador construído em cima de \s apaga em silêncio os espaços que você lutou para manter num "R$ 1.200,00". Aqui só espaço, tabulação, quebra de linha, retorno de carro e form feed contam como colapsáveis.

Os cinco elementos que não podem ser reindentados

Dentro de <pre> e <textarea>, espaço em branco é conteúdo. Cada espaço, cada tabulação e cada quebra de linha aparece na tela exatamente como está escrito, porque esses elementos recebem white-space: pre da folha de estilo do próprio navegador. Somar dois espaços de indentação nas linhas de um bloco de código é editar o exemplo de código da página. Somar uma quebra de linha depois de <textarea> é mudar o valor padrão de um campo de formulário. Esse é o erro mais comum em formatadores de HTML, e ele é silencioso: o arquivo continua válido, a página continua carregando, só o conteúdo saiu do lugar.

<script> e <style> são um risco de outra natureza. O conteúdo deles não é HTML: é texto cru, e o parser é obrigado a ler até a tag de fechamento correspondente sem interpretar nada no meio. Ou seja, if (a < b) dentro de um script é uma comparação, não o começo de um elemento <b>. Formatador que varre o arquivo inteiro com uma expressão regular erra exatamente aqui e começa a "fechar" tags que nunca abriram, corrompendo tudo que vem depois daquele ponto.

Reindentar o corpo de um script costuma ser seguro, e a ferramenta faz isso — só que apenas quando não há crase no código. Dentro de um template literal a indentação faz parte da string, então mexer nela muda o que o script produz. Assim que aparece uma crase, o conteúdo sai idêntico ao que entrou. Preferir "intacto e um pouco feio" a "bonito e possivelmente errado" é a troca que sustenta a ferramenta inteira. CSS recebe o mesmo tratamento, e <code> também sai byte a byte igual, já que quase sempre ele mora dentro de um <pre>.

Tag void, fechamento opcional e a árvore que escorrega

O nível de indentação vem de uma pilha, e a pilha só funciona se o parser souber quais tags de fato abrem um nível. Quatorze elementos do HTML são void: br, img, input, meta, link, hr, source e companhia. Eles não têm fechamento e não têm filhos. Basta empilhar um <br> para que toda linha seguinte fique um nível mais à direita, para sempre, porque o desempilhamento nunca chega. Dá para reconhecer essa falha de longe: a saída vira uma escada rolando para o lado direito da tela.

O problema espelhado é o fechamento opcional. </li>, </p>, </td>, </tr> e </option>, entre outros, podem ser omitidos sem que o HTML deixe de ser válido — e template de verdade omite o tempo todo. Um parser que exige o fechamento lê <li>um<li>dois</ul> como item de lista aberto e ou desiste, ou aninha o segundo item dentro do primeiro. Aqui as regras de fechamento implícito estão implementadas: um novo <li> fecha o anterior, <tr> fecha a célula aberta, <tbody> fecha o <thead>, e qualquer tag de bloco fecha um <p> em aberto. Os nomes de tag são comparados sem diferenciar maiúscula de minúscula, mas impressos com a caixa original — é o que faz o <linearGradient> e o viewBox de um SVG continuarem funcionando, já que colocar tudo em minúscula quebra o gráfico.

Quando a estrutura realmente não fecha — um <div> aberto de verdade, uma tag de fechamento órfã, um comentário ou uma aspa sem fim — a ferramenta para e devolve a sua entrada com o motivo. Essa recusa é o recurso principal. A alternativa é um documento com cara de formatado que perdeu um galho inteiro da árvore no caminho.

HTML formatado e HTML válido são coisas diferentes

Muita gente chega num formatador esperando que ele conserte o arquivo, e ele não conserta, porque as duas tarefas quase não se encostam. Formatar é uma operação sobre espaço em branco: entra uma árvore, sai a mesma árvore com outras quebras de linha. Validar é perguntar se o documento obedece à especificação — se os id são únicos, se um <div> pode estar dentro de um <p> (não pode), se a <img> tem alt, se aquele atributo inventado existe.

HTML lindamente indentado pode falhar em vinte pontos da validação, e HTML minificado e ilegível pode passar limpo. O único sinal que um formatador honestamente entrega é estrutural: se esta ferramenta recusou seu arquivo, o aninhamento das tags está mesmo errado e o validador vai confirmar. Para todo o resto, use o validador Nu do W3C, que responde uma pergunta que nenhum formatador tem competência para responder.

Quando minificar compensa e quando o gzip já resolveu

Minificar HTML é tirar o espaço entre as tags, colapsar sequências de espaço dentro do texto e, opcionalmente, remover comentários. O detalhe é que cada uma dessas economias é exatamente aquilo em que um algoritmo de compressão é melhor. Indentação repetida é o padrão de bytes mais compressível que existe, então gzip e Brotli normalmente já tiraram isso antes do arquivo chegar na rede.

Situação Minificar ajuda?
Página estática servida com gzip ou Brotli Quase nada — poucos por cento em cima da compressão
HTML guardado numa coluna do banco ou num campo JSON Sim — não há compressão ali e você paga por linha
Template de e-mail marketing Sim — o Gmail corta a mensagem por volta de 102 kB
HTML embutido como string dentro do JavaScript Sim — ele entra no bundle com o tamanho cheio
Página que você ainda vai depurar em produção Não — troca legibilidade por bytes que você já tinha

Comentário é a parte interessante da minificação. Remover costuma ser de graça, com uma exceção que a ferramenta trata na unha: comentário condicional (<!--[if lt IE 9]>) é lógica, não anotação. Ele fica mesmo com a remoção ligada, porque apagá-lo muda o comportamento no único navegador que o lê. Diretiva de build escondida em comentário merece o mesmo cuidado, e é para isso que a caixa de seleção existe.

Formatador do editor ou formatador online?

Se você está dentro de um projeto, o editor ganha com folga. Prettier, ou o formatador embutido do VS Code, do WebStorm e do Zed, roda ao salvar, aplica a mesma regra em todo arquivo e pode ser cobrado na integração contínua, para que a configuração de ninguém saia do combinado. Formatação deveria ser propriedade do repositório, não algo que alguém lembra de fazer.

O formatador online ganha justamente onde o editor não está no caminho: um pedaço de HTML copiado de uma conversa, o corpo de uma resposta capturada no DevTools, um template colado de um campo do CMS, um trecho recebido de um colega numa máquina em que você não pode instalar nada, ou uma conferida rápida no celular. Também é a forma mais rápida de entender a estrutura de um markup que não é seu: cola, clica e o aninhamento fica legível. No momento em que aquele trecho vira arquivo de repositório, devolva o trabalho para o editor.

O que acontece com o seu arquivo

Nada sai da aba. A ferramenta é uma página estática: o parser, o formatador, o minificador e o destaque de sintaxe são JavaScript que baixa uma vez e depois roda localmente. Escolher um arquivo usa o FileReader, que lê direto do seu disco; não existe upload, nem armazenamento temporário, nem requisição carregando o seu markup. Carregue a página, desconecte e ela continua formatando.

Isso importa mais em HTML do que se imagina. Markup real carrega token de sessão em input escondido, chave de API em script inline, nome de cliente em template de e-mail, hostname interno em atributo src e texto não publicado dentro de comentário. Colar qualquer uma dessas coisas num formatador que dá a volta por um servidor é vazamento, por mais bem-intencionado que seja o servidor. Aqui não há limite de tamanho, cadastro nem cota, porque não existe nada do outro lado para proteger.

Perguntas frequentes

O HTML que eu colo sai do meu computador?

Não sai. O parser, o formatador e o minificador são JavaScript que vem junto com a página e roda na sua aba. Abrir um arquivo usa o FileReader do próprio navegador, que lê do disco sem nenhuma requisição de rede. Dá para desligar a internet depois que a página carregou e continuar formatando — esse é o teste honesto, e boa parte dos formatadores online reprova nele porque manda seu HTML para um servidor.

Formatar pode mudar como a minha página aparece?

É exatamente isso que a ferramenta foi construída para não fazer. O conteúdo de pre, textarea, code, script e style sai byte a byte igual ao que entrou, e uma quebra de linha só entra onde já havia espaço em branco ou na borda de uma caixa de bloco, onde o navegador descarta esse espaço. A única suposição que pode falhar é o CSS: se você aplicou white-space: pre ou display: inline num elemento cujo nome diz outra coisa, nenhum formatador que olha só a tag tem como saber.

Por que ele recusou meu arquivo e devolveu tudo igual?

Porque encontrou algo que não dá para resolver sem chutar: uma tag aberta e nunca fechada, uma tag de fechamento sem abertura, um comentário sem fim ou aspas que não fecham. Chutar é como formatador corrompe documento em silêncio. A mensagem diz em qual tag ele travou; corrija aquele ponto e o resto formata normalmente.

Ele conserta HTML inválido?

Não, e nenhum formatador deveria. Formatar mexe em espaço em branco; validar é outra pergunta, a de saber se o documento obedece à especificação. Um arquivo pode estar perfeitamente indentado e mesmo assim ter um div dentro de um p, dois elementos com o mesmo id e imagens sem alt. Para isso existe o validador do W3C.

Quanto a minificação economiza de verdade?

Em bytes crus, normalmente entre 10% e 25% do arquivo. Na rede, muito menos: gzip e Brotli já comprimem indentação repetida a quase nada, então sobra pouco — quase sempre menos de 5% em cima da compressão. O ganho real aparece em template de e-mail, em HTML guardado dentro de uma coluna do banco e em HTML embutido como string dentro do JavaScript, lugares onde não existe camada de compressão nenhuma.