Entidades HTML e os cinco caracteres que realmente precisam de uma

Uma entidade HTML é um jeito de escrever um caractere usando só ASCII puro, para que o navegador mostre aquele caractere em vez de lê-lo como markup. & produz um ampersand, < produz um sinal de menor que, — produz um travessão. Numa página UTF-8 — que hoje é qualquer página — só cinco caracteres chegam a precisar disso, e só dois precisam em todo lugar. Acentos, setas, símbolos de moeda e emoji você digita direto no arquivo, e as entidades que aparecem para eles em tutoriais antigos são resquícios de uma época em que não dava.

As três formas de escrever o mesmo caractere

Toda entidade é uma referência de entidade: um ampersand, um nome ou um número, e um ponto e vírgula. São três formas, e os navegadores tratam todas como idênticas.

• Com nome — &,  , ©. Fáceis de ler, mas só funcionam para os caracteres a que alguém se deu ao trabalho de dar nome. A lista de nomes do padrão HTML é fixa e não vai ser ampliada.
• Decimal — &. O code point Unicode em base 10.
• Hexadecimal — &. O mesmo code point em base 16, que é como os code points Unicode são escritos em todo o resto, então U+2014 vira — sem conta nenhuma.

As três formas com ampersand produzem o mesmo caractere. As referências numéricas existem para tudo o que o Unicode consegue expressar; as com nome, só para a lista curta, e é por isso que os escapadores acabam recorrendo aos números. O encoder daqui mantém uma lista propositalmente curta — cerca de setenta nomes que parsers antigos e clientes de e-mail reconhecem de forma confiável — e escreve todo o resto como número.

O ponto e vírgula final é necessário?

O HTML5 decodifica cerca de cem referências com nome antigas mesmo sem o ponto e vírgula final, por compatibilidade com páginas escritas em 1998. Então &copy no texto do corpo aparece como ©, você querendo ou não. Isso é uma armadilha, não um recurso: parsers de XML, SVG e RSS rejeitam a mesma coisa de cara, e o XML define só cinco entidades com nome no total — amp, lt, gt, quot e apos. Escreva o ponto e vírgula.

Quais caracteres você realmente precisa escapar?

Cinco, e só porque senão o parser leria cada um deles como algo que não é texto.

• & — sempre. É o que começa uma referência de entidade, então um sem escapar seguido de letras pode ser engolido.
• < — sempre no conteúdo de texto. É o que começa uma tag.
• > — por convenção, mais do que por necessidade estrita. Custa quatro caracteres e elimina uma categoria inteira de casos extremos.
• " e ' — dentro de valores de atributo, aquele que você usou como aspa. Escapar os dois significa nunca ter que conferir qual era.

O caso do ampersand é o que gera discussão. AT&T aparece certo, porque &T não é uma referência. Salt & Pepper também está ok. Mas uma query string como ?page=2&copy=full contém &copy, e em texto visível isso vira ?page=2©=full. Dentro de um valor de atributo o HTML5 tem uma regra especial que te salva — um nome sem ponto e vírgula seguido de = ou de uma letra ou dígito é deixado como está — que é exatamente o tipo de exceção da qual você não quer depender. Escape o ampersand e pare de pensar nisso.

Fazer isso a olho num bloco de texto é lento e fácil de fazer pela metade. Um escapador com modo mínimo converte esses cinco e deixa todo o resto como caracteres reais, que é a saída correta para uma página UTF-8 e mantém o código-fonte legível.

O que você pode parar de escapar

Se o seu documento declara <meta charset="utf-8"> e está mesmo salvo como UTF-8, digite o caractere. Um travessão, um ı turco, um ₹, um 🙂 — todos funcionam como texto literal, e todos são mais curtos, mais legíveis e menos sujeitos a erro do que — e companhia.

As entidades continuam sendo a melhor escolha para os caracteres que são invisíveis ou ambíguos no código-fonte, porque ninguém consegue revisar o que não vê:

•   — um espaço não separável, U+00A0. No seu editor ele parece idêntico a um espaço normal e não se comporta como um.
• ­ — um hífen opcional, que só aparece se a palavra quebrar naquele ponto.
• ​, o espaço de largura zero, e o joiner e o non-joiner ao lado dele — genuinamente invisíveis, então a próxima pessoa vai apagá-los sem querer.

Vale a pena entender direito o espaço não separável. Espaços normais colapsam: dez seguidos aparecem como um. Um espaço não separável não colapsa, e não permite quebra de linha. É por isso que 5 kg nunca termina com o 5 numa linha e o kg na seguinte, e é a correção certa para um número separado da sua unidade. Escrever um de propósito é o caso fácil. Achar os que outra pessoa deixou nos seus dados é o caso difícil, e é outro trabalho.

Por que a minha página mostra & em vez de &?

Porque alguma coisa escapou um texto que já estava escapado. O ampersand de & foi escapado uma segunda vez e virou &, e o navegador decodifica fielmente uma camada e imprime o resto.

É um problema de pipeline, não um erro de digitação. Um formulário escapa a entrada ao salvar, o template escapa de novo ao renderizar, e a segunda passada não tem como saber que a primeira aconteceu. O estrago se acumula de forma previsível, então decodificar a string repetidamente até ela parar de mudar diz quantas camadas existem. Depois tire o passo de escape que não deveria estar rodando. Escapar uma vez só, no ponto de saída, é o único arranjo que não acaba produzindo isso.

Entidades, URL encoding e escape JSON: o que vai onde?

Três sistemas de escape diferentes, três alfabetos diferentes, aplicados em três momentos diferentes. Um espaço é   em HTML, %20 numa URL e \u0020 em JSON, e usar um no lugar do outro produz um texto que parece quase certo e está quebrado.

A sobreposição que causa mais estrago é um link. O href é HTML, então leva escape de entidade; o que está dentro dele é uma URL, então os caracteres reservados dela precisam de percent-encoding antes. Os dois, nessa ordem. Se você já viu um link quebrar no instante em que alguém colocou um espaço ou um sinal de mais num parâmetro, as regras por trás do percent-encoding são a metade da resposta que as entidades não cobrem.

JSON é um mundo à parte de novo. Entidades HTML não significam nada dentro de uma string JSON — são só caracteres — e os escapes \u do JSON não significam nada para um parser HTML. Quando uma resposta chega como uma única linha ininterrupta de sequências escapadas, formatar antes de tentar ler diz em segundos se o problema são os dados ou a codificação.

Escapar é suficiente para impedir XSS?

No texto HTML e em valores de atributo entre aspas, escapar esses cinco é o que impede que o markup injetado seja markup. Fora desses dois lugares, isso ajuda muito menos do que parece. Escapar faz o markup aparecer como texto; não remove nada, e só é correto para o contexto em que você está escrevendo. Quatro lugares onde não basta:

• Atributos sem aspas. <div class=VALUE> termina no primeiro espaço, então escapar aspas não adianta nada. Coloque aspas nos atributos.
• Dentro de <script>. Ali é um contexto de string JavaScript. Referências de entidade não são decodificadas ali de jeito nenhum, e a sequência literal </script> dentro de uma string ainda encerra o bloco.
• Dentro de um atributo de URL. javascript:alert(1) não contém nada que um escapador fosse tocar, então escapar deixa um link funcionando. E entidades num href são decodificadas antes de a URL ser parseada, então um filtro que procura o texto literal javascript: passa direto por javascript: — j é um j. Em vez disso, confira o esquema.
• Dentro de CSS. Outras regras de escape de novo.

E se você quer manter algumas tags e descartar outras — permitir <b>, rejeitar <script> — isso é sanitizar, e exige um parser de verdade com uma allowlist. Escapar é tudo ou nada por design.

Por que meu emoji saiu como duas entidades quebradas?

Caracteres acima de U+FFFF — emoji, CJK mais raro, quase todas as escritas históricas — são guardados em JavaScript como duas unidades de código. Um escapador que percorre uma string um índice por vez emite duas referências como ��, e nenhum parser consegue juntar isso de volta; o HTML transforma cada metade num caractere de substituição. Um escapador correto itera por code point, então um rosto sorridente vira uma única referência, 😀. Se você já viu uma fileira de losangos pretos onde deveria estar um emoji, normalmente é por isso.

Referências numéricas entre € e Ÿ dão problema de outro jeito. Os parsers HTML deliberadamente não exibem essas referências como os caracteres de controle Unicode que elas nomeiam; eles mapeiam para os caracteres do Windows-1252 que os autores queriam nos anos 1990, então — sai como um travessão. Correto segundo o padrão, nada óbvio, e mais um motivo para digitar o caractere em vez do número.

Última atualização 19 de setembro de 2026