HTML Encode e Decode online

O que é HTML encode (escape) e HTML decode

No HTML, alguns caracteres não são texto comum: o < abre uma tag, o & começa uma entidade e as aspas delimitam o valor de um atributo. Quando esses caracteres precisam aparecer como texto, eles têm de ser trocados pelas entidades equivalentes — e é isso que o HTML encode faz. Sem a troca, o navegador tenta interpretar o trecho como marcação: um < perdido no meio de um parágrafo pode engolir o restante da frase.

Uma entidade pode ser nomeada, quando usa um apelido do padrão (&, ©), ou numérica, quando aponta direto para o code point Unicode em decimal (©) ou hexadecimal (©). O HTML decode reconhece as três formas e devolve o caractere original.

Quando usar encode e quando usar decode

Tabela de entidades HTML mais usadas

As seis primeiras são as que realmente importam no dia a dia. As seguintes são os acentos do português: você não precisa codificá-los num documento UTF-8, mas vai encontrá-los assim em conteúdo vindo de sistema antigo, e é justamente aí que o decode resolve.

Exemplos de antes e depois

Texto com acentos vindo de sistema antigo (decode)

Entrada:   <p>Ol&aacute;, cora&ccedil;&atilde;o</p>
Resultado: <p>Olá, coração</p>

Trecho de código para publicar num artigo (encode)

Entrada:   <script>alert(1)</script>
Resultado: &lt;script&gt;alert(1)&lt;/script&gt;

JSON de log com aspas escapadas (decode)

Entrada:   {"nivel":"erro","msg":"falha ao gravar"}
Resultado: {"nivel":"erro","msg":"falha ao gravar"}

Valor que vai para dentro de um atributo (encode)

Entrada:   Ferramentas & Utilitários
Resultado: Ferramentas & Utilitários
Uso:       <a title="Ferramentas &amp; Utilitários">…</a>

Como fazer HTML encode e decode em C#

O caminho padrão hoje é WebUtility, do namespace System.Net: está na biblioteca base, não exige referência a System.Web e funciona em qualquer projeto .NET.

using System.Net;

var codificado = WebUtility.HtmlEncode("<p>Olá & bem-vindo</p>");
// &lt;p&gt;Olá &amp; bem-vindo&lt;/p&gt;

var original = WebUtility.HtmlDecode(codificado);
// <p>Olá & bem-vindo</p>

Dentro do ASP.NET Core existe um segundo encoder, o HtmlEncoder de System.Text.Encodings.Web. É ele que o Razor aplica sozinho toda vez que você escreve uma expressão numa view — e é por isso que @Html.Raw é a única forma de emitir HTML sem escape, e a única que precisa de revisão cuidadosa. O HttpUtility.HtmlEncode de System.Web ainda existe, mas é legado do .NET Framework: não há motivo para escolhê-lo em código novo.

O encoder padrão e os nossos acentos

Há uma armadilha que só aparece em português. O HtmlEncoder padrão do ASP.NET Core escapa tudo que está fora do ASCII, por segurança — então ç vira ç e ã vira ã no HTML servido. A página exibe certo, porque o navegador decodifica; mas o fonte fica ilegível, o arquivo cresce e qualquer comparação de texto sobre o HTML passa a falhar.

A correção não é desligar o escape — é dizer ao encoder quais faixas Unicode não precisam dele:

builder.Services.Configure<WebEncoderOptions>(opcoes =>
{
    opcoes.TextEncoderSettings = new TextEncoderSettings(UnicodeRanges.All);
});

Os caracteres com significado em HTML — <, >, & e as aspas — continuam escapados. Só os acentos deixam de ser. Este site roda exatamente com essa configuração.

Em JavaScript

Para codificar, basta um replace sobre os cinco caracteres — em uma passagem, nunca encadeando chamadas: se o & for tratado depois do <, o & recém-escrito é escapado de novo e < vira <.

Para decodificar, o caminho que circula na internet é jogar o texto inteiro no innerHTML de um <textarea> e ler o value. Funciona na maioria dos casos e falha em dois que importam: um </textarea> no meio da entrada encerra o modo de texto do parser, e tudo que vem depois some do resultado, em silêncio — numa ferramenta de conversão, perder metade do texto sem avisar é pior que qualquer outra falha. E, a partir daquele ponto, o conteúdo volta a ser interpretado como marcação. Esta ferramenta contorna os dois casos deixando o parser resolver uma referência de cada vez, nunca o documento inteiro.

E não use DOMParser com textContent para essa tarefa: ele devolve o texto sem as tags, então <b>oi</b> volta como oi. É extração de texto, não decodificação.

Cuidado: HTML encode não é sanitização

Escapar e sanitizar são coisas diferentes, e confundi-las é como a maioria das falhas de XSS nasce. O escape correto depende do contexto de saída, e são cinco contextos com regras próprias: o corpo do HTML, o valor de um atributo, o interior de um bloco JavaScript, uma URL e uma folha de estilo. O HTML encode resolve os dois primeiros — e só.

Um <script> escrito no corpo do documento é inofensivo. Mas o mesmo valor escapado, colocado num atributo sem aspas, continua explorável: basta um espaço no conteúdo para o atacante acrescentar um atributo novo. E decodificar a entrada do usuário para depois renderizá-la é exatamente o caminho por onde o buraco reaparece.

A regra prática tem duas partes. Primeira: escape na saída, no contexto daquela saída — nunca "limpe" o dado na entrada, porque na entrada ainda não se sabe onde ele será usado. Segunda: quando você precisa aceitar HTML de verdade (o corpo de um artigo, por exemplo), escape não basta — aí o caminho é um sanitizador com lista de permissão, que remove tag e atributo perigosos em vez de escapá-los. O guia de prevenção a XSS da OWASP detalha as regras de cada contexto.

Perguntas frequentes

Os dados que eu colo aqui são enviados para algum servidor?

Não. O texto que você cola nesta ferramenta não é enviado a lugar nenhum: a conversão acontece inteiramente no seu navegador, em JavaScript, e o resultado nunca sai da sua máquina. Dá para conferir sem depender da nossa palavra — abra o DevTools do navegador na aba Network e clique em converter: nenhuma requisição nova parte. É por isso que esta página serve para texto que você não colaria numa ferramenta online qualquer.

Posso usar o HTML encode para escapar a senha da minha connection string?

Só quando a connection string vai para um web.config, porque ali ela vive dentro de um atributo XML e o escape é o mesmo do HTML: o E comercial vira &, o menor vira <, o maior vira > e a aspa dupla vira ". Para appsettings.json o HTML encode dá a resposta ERRADA — em JSON o que precisa de escape é a barra invertida e a aspa dupla, e um E comercial transformado em & produz uma senha inválida sem nenhuma mensagem de erro útil. Ao todo são cinco camadas diferentes, cada uma com o seu escape: o valor dentro da própria connection string ADO.NET (que exige aspas quando a senha tem ponto e vírgula, igual, aspa ou espaço nas pontas, e dobra as aspas internas — o NpgsqlConnectionStringBuilder resolve isso por você), o JSON do appsettings, o XML do web.config, a URI no formato postgresql://usuario:senha@host (que pede percent-encoding, e é o formato que a DigitalOcean entrega) e o quoting do shell quando a string vai numa variável de ambiente.

Por que meu texto aparece com " e ' em vez das aspas?

Porque o texto passou por um HTML encode em algum ponto do caminho e ninguém desfez a conversão. Isso acontece tipicamente quando um valor já escapado é gravado no banco e depois escapado de novo na exibição, ou quando você copia conteúdo de um log que registrou a versão codificada. A correção imediata é aplicar o HTML decode uma vez; a correção de verdade é escapar apenas na saída, nunca na gravação.

Qual a diferença entre HTML encode e URL encode?

O HTML encode protege caracteres que têm significado na marcação HTML, trocando-os por entidades: o E comercial vira & e o menor vira <. O URL encode protege caracteres que têm significado num endereço, trocando-os por percent-encoding: o espaço vira %20 e o arroba vira %40. São tabelas diferentes para contextos diferentes, e usar uma no lugar da outra não dá erro — apenas produz um valor que não funciona. Um espaço codificado como   dentro de uma URL continua quebrado.

Preciso codificar acentos como á em português?

Não. Se o documento declara UTF-8 — e todo HTML atual deveria declarar, com a meta charset no topo — você escreve á, ç e ã diretamente e o navegador exibe corretamente. Codificar acento em entidade é herança da época em que a codificação do documento era incerta; hoje só deixa o HTML maior e mais difícil de ler. As únicas entidades realmente obrigatórias são as dos caracteres com significado na marcação: &, <, > e ".

Qual a diferença entre entidade nomeada e entidade numérica?

A entidade nomeada usa um apelido definido pelo padrão HTML, como © para o símbolo de copyright, e existem cerca de 2.200 desses nomes. A entidade numérica aponta diretamente para o code point Unicode do caractere, em decimal (©) ou em hexadecimal (©), e por isso funciona para qualquer caractere existente, inclusive os que não têm nome. As duas produzem exatamente o mesmo caractere na tela: a nomeada é mais legível e a numérica é mais abrangente.

Qual a diferença entre ' e '?

As duas representam o apóstrofo, mas ' não existe em HTML4 — ela foi definida em XML e só entrou no HTML a partir do HTML5. Um navegador antigo, ou um parser de XHTML servido como HTML4, exibe o texto literal ' em vez do apóstrofo. A forma numérica ' funciona em todas as versões, e é por isso que o ASP.NET Core, o Razor e a maioria das bibliotecas de escape emitem ' e não '.

HTML encode protege contra XSS?

Protege apenas quando é aplicado na saída e no contexto certo, e por isso não pode ser tratado como sanitização. O escape correto depende de onde o valor vai parar: dentro do corpo do HTML, dentro de um atributo, dentro de um bloco JavaScript, dentro de uma URL ou dentro de CSS — cada um desses tem regras próprias, e o escape de HTML só resolve os dois primeiros. Um script escapado no corpo do documento é inofensivo, mas um valor escapado colocado num atributo SEM aspas continua explorável. A regra prática é escapar na saída, no contexto daquela saída, e nunca limpar o dado na entrada — porque na entrada ainda não se sabe onde ele será usado.

Como fazer HTML encode e decode em C#?

Use WebUtility.HtmlEncode e WebUtility.HtmlDecode, do namespace System.Net: as duas estão na biblioteca base, não exigem referência a System.Web e funcionam em qualquer projeto .NET. Dentro do ASP.NET Core, o encoder usado por padrão é o HtmlEncoder de System.Text.Encodings.Web, que o Razor aplica sozinho toda vez que você escreve uma expressão numa view — e que NÃO é aplicado quando você usa Html.Raw. O HttpUtility.HtmlEncode de System.Web ainda existe, mas é legado do .NET Framework e não há motivo para escolhê-lo em código novo.

Outras ferramentas

Confundiu com o outro escape? O URL Encode e Decode trata dos caracteres que têm significado num endereço — o espaço vira %20 e o & vira %26 —, que é um problema diferente deste. Todas as ferramentas estão em ferramentas para desenvolvedor: rodam no navegador, sem cadastro e sem anúncio.