' for inserido em um formulário e exibido sem codificação, o script executa no navegador das vítimas. Ao codificar a saída — transformando '<' em '<' e '>' em '>' — o texto é exibido como caracteres literais e não como código executável. É uma das defesas mais fundamentais em desenvolvimento web seguro."}},{"@type":"Question","name":"Qual a diferença entre entidades HTML nomeadas e numéricas?","acceptedAnswer":{"@type":"Answer","text":"Entidades nomeadas têm um nome legível: '©' (©), '€' (€), '<' (<). Entidades numéricas usam o código Unicode do caractere: '©' para © (decimal) ou '©' (hexadecimal). Ambas produzem o mesmo resultado. Entidades numéricas têm a vantagem de funcionar com qualquer caractere Unicode, mesmo os que não têm nome definido em HTML. Para os caracteres reservados básicos (<, >, &, \", '), sempre use entidades nomeadas por legibilidade."}},{"@type":"Question","name":"O que são seções CDATA e quando usá-las como alternativa?","acceptedAnswer":{"@type":"Answer","text":"CDATA (Character Data) é uma seção em XML e XHTML onde o conteúdo é tratado como texto literal, não como marcação. A sintaxe é: & sem codificação ]]>. Em XHTML estrito, scripts e estilos inline usavam CDATA para evitar conflito com o parser XML. Em HTML5 puro, CDATA não é interpretado da mesma forma e a codificação de entidades continua sendo a abordagem mais compatível e segura para exibir caracteres especiais em conteúdo de texto."}},{"@type":"Question","name":"Quando a codificação no servidor é obrigatória vs. opcional no cliente?","acceptedAnswer":{"@type":"Answer","text":"A codificação de saída no servidor é obrigatória para qualquer dado inserido pelo usuário que seja renderizado como HTML — comentários, nomes, endereços, campos de busca. Frameworks modernos como React, Vue e Angular fazem isso automaticamente ao usar interpolação padrão ({variavel} ou {{variavel}}), mas uso de innerHTML ou dangerouslySetInnerHTML bypassa essa proteção. No servidor, funções como htmlspecialchars() no PHP, html.escape() no Python e HtmlEncoder.Default.Encode() no .NET são as ferramentas corretas."}}]}]}
Snivy
Entrar em contato

Ferramentas

Codificador e Decodificador de HTML

Codifique texto para entidades HTML ou decodifique entidades de volta para texto legível. Essencial para exibir código como texto em páginas web e para prevenir vulnerabilidades XSS.

Codificador e Decodificador de HTML

Texto original
HTML com entidades

Entidades HTML: a ponte entre código e texto visível

HTML reserva alguns caracteres para uso próprio como parte da sintaxe da linguagem: os sinais de menor e maior que (< e >) delimitam tags, o E comercial (&) inicia entidades, as aspas delimitam atributos. Quando você precisa exibir esses caracteres como texto na página, não pode usá-los diretamente — o navegador os interpretaria como marcação. A solução são as entidades HTML, que representam esses símbolos de forma que o parser os trate como conteúdo e não como estrutura.

Esta ferramenta faz a conversão nos dois sentidos: codifica texto comum para a representação em entidades HTML (útil para incluir código de exemplo em artigos e documentação), ou decodifica entidades de volta para o texto legível original (útil para limpar conteúdo duplamente codificado ou visualizar o texto original de um fragmento HTML copiado de uma fonte).

Por que entidades HTML existem e quais são as mais importantes

As cinco entidades mais críticas são: &lt; para <, &gt; para >, &amp; para &, &quot; para " e &apos; para '. Esses são os únicos caracteres que precisam ser codificados obrigatoriamente em HTML para que o documento seja válido. Existem centenas de entidades nomeadas adicionais para símbolos matemáticos, moedas, letras acentuadas e caracteres tipográficos como travessão (&mdash;), reticências (&hellip;) e espaço não-quebrável (&nbsp;).

Com o advento do UTF-8 como encoding padrão na web, a necessidade de entidades para caracteres acentuados (como &atilde; para ã ou &ccedil; para ç) diminuiu: é mais simples e legível incluir o próprio caractere no HTML quando o arquivo está salvo em UTF-8. A exceção são os cinco caracteres reservados acima, que sempre precisam de codificação independentemente do encoding do documento.

XSS: quando a falta de codificação vira vulnerabilidade de segurança

Cross-Site Scripting (XSS) é consistentemente uma das vulnerabilidades mais prevalentes na web, figurando no OWASP Top 10 há mais de uma década. O ataque explora a ausência de codificação de saída: se um campo de comentário aceita texto livre e esse texto é exibido em HTML sem ser codificado, um atacante pode inserir uma tag <script> que executa código malicioso no navegador de outros usuários.

As consequências vão desde roubo de cookies de sessão (permitindo hijacking de contas) até phishing (redirecionamento para páginas falsas), keylogging (captura de digitação em formulários) e mineração de criptomoedas no navegador da vítima. A defesa mais eficaz é simples: nunca inserir conteúdo de usuário em HTML sem codificar primeiro. Frameworks modernos fazem isso automaticamente, mas código legado ou uso descuidado de APIs DOM ainda é fonte frequente de vulnerabilidades XSS.

Codificação em contextos diferentes: HTML, atributos, JavaScript e URLs

O contexto onde um dado é inserido determina qual tipo de codificação é necessário. No corpo do HTML (entre tags), codificação de entidades para os cinco caracteres reservados é suficiente. Em atributos HTML, as aspas também precisam ser codificadas (&quot;). Em strings JavaScript inline, a codificação é diferente: usa-se escapes JavaScript (\', \", \n). Em URLs, usa-se percent-encoding (%20 para espaço, %26 para &).

Misturar os contextos é uma fonte comum de bugs e vulnerabilidades. Inserir HTML-encoded em uma string JavaScript cria conteúdo inesperado; inserir texto não-codificado em um atributo href pode permitir injeção de javascript: URLs. Ferramentas de análise de segurança como Snyk, SonarQube e Burp Suite identificam esses erros de contexto automaticamente em revisões de código.

Codificação dupla: quando entidades são codificadas mais de uma vez

Um problema comum em sistemas que processam HTML em múltiplas etapas é a codificação dupla: &amp;lt; em vez de &lt;. Isso acontece quando um sistema codifica dados já codificados, resultando em texto que exibe literalmente "&lt;" na página em vez de "<". O problema é visível especialmente em editores WYSIWYG, sistemas de comentários e plataformas que processam conteúdo em pipeline de várias transformações.

A solução é garantir que a codificação aconteça exatamente uma vez, no momento em que o dado bruto é inserido em contexto HTML. Dados que já estão em formato HTML (como conteúdo de um CMS) não devem ser codificados novamente. Esta ferramenta pode ajudar a diagnosticar codificação dupla: se ao decodificar o resultado ainda contém entidades HTML, o conteúdo original foi codificado mais de uma vez.

Perguntas frequentes

O que são entidades HTML e por que elas existem?

Entidades HTML são sequências de caracteres que representam símbolos reservados ou especiais no HTML. O HTML usa '<' e '>' para delimitar tags; se você quiser exibir esses caracteres como texto, precisa usar '&lt;' e '&gt;'. O '&' inicia entidades, então ele mesmo precisa ser representado como '&amp;'. Outros caracteres como aspas ('&quot;'), apóstrofo ('&apos;') e símbolos especiais (©, ®, €) também têm representações em entidades.

Por que usar &amp; em vez de & diretamente no HTML?

O caractere '&' inicia uma entidade HTML. Se você escrever '&copy;' no HTML, o navegador exibirá '©'. Mas se você quiser exibir '&copy;' literalmente como texto, precisa escrever '&amp;copy;'. Usar '&' diretamente em HTML — especialmente em URLs dentro de atributos href — pode causar comportamento inesperado em validadores e alguns navegadores. A boa prática é sempre codificar '&' como '&amp;' em atributos HTML.

Como a codificação HTML previne ataques XSS?

XSS (Cross-Site Scripting) ocorre quando um atacante injeta código JavaScript malicioso em uma página web via campos de entrada do usuário. Se um comentário como '<script>document.cookie</script>' for inserido em um formulário e exibido sem codificação, o script executa no navegador das vítimas. Ao codificar a saída — transformando '<' em '&lt;' e '>' em '&gt;' — o texto é exibido como caracteres literais e não como código executável. É uma das defesas mais fundamentais em desenvolvimento web seguro.

Qual a diferença entre entidades HTML nomeadas e numéricas?

Entidades nomeadas têm um nome legível: '&copy;' (©), '&euro;' (€), '&lt;' (<). Entidades numéricas usam o código Unicode do caractere: '&#169;' para © (decimal) ou '&#xA9;' (hexadecimal). Ambas produzem o mesmo resultado. Entidades numéricas têm a vantagem de funcionar com qualquer caractere Unicode, mesmo os que não têm nome definido em HTML. Para os caracteres reservados básicos (<, >, &, ", '), sempre use entidades nomeadas por legibilidade.

O que são seções CDATA e quando usá-las como alternativa?

CDATA (Character Data) é uma seção em XML e XHTML onde o conteúdo é tratado como texto literal, não como marcação. A sintaxe é: <![CDATA[ conteúdo com < > & sem codificação ]]>. Em XHTML estrito, scripts e estilos inline usavam CDATA para evitar conflito com o parser XML. Em HTML5 puro, CDATA não é interpretado da mesma forma e a codificação de entidades continua sendo a abordagem mais compatível e segura para exibir caracteres especiais em conteúdo de texto.

Quando a codificação no servidor é obrigatória vs. opcional no cliente?

A codificação de saída no servidor é obrigatória para qualquer dado inserido pelo usuário que seja renderizado como HTML — comentários, nomes, endereços, campos de busca. Frameworks modernos como React, Vue e Angular fazem isso automaticamente ao usar interpolação padrão ({variavel} ou {{variavel}}), mas uso de innerHTML ou dangerouslySetInnerHTML bypassa essa proteção. No servidor, funções como htmlspecialchars() no PHP, html.escape() no Python e HtmlEncoder.Default.Encode() no .NET são as ferramentas corretas.