Por que o cliente não consegue abrir o arquivo HTML que você mandou

Você gerou uma proposta em HTML, abriu no seu navegador, ficou boa. Mandou por e-mail. O cliente respondeu "chegou um monte de código aqui", ou "não consigo abrir", ou pior, não respondeu nada.

O arquivo não está corrompido e você não fez nada errado. Um arquivo .html só vira página quando um navegador o interpreta. Fora do navegador, dentro do Outlook na web, do visualizador de anexos do celular, do WhatsApp, ele é tratado como arquivo de texto. E arquivo de texto é exibido como texto: o código que você escreveu.

A parte que quase ninguém explica é por que os aplicativos se recusam a renderizar. Não é preguiça de quem programou: é uma decisão de segurança documentada, e entender isso resolve o problema de vez.

O que acontece quando alguém recebe um arquivo .html

O arquivo chega inteiro. O que muda é quem tenta abri-lo.

O padrão é claro: fora do navegador, HTML não é uma página, é um arquivo de texto com marcações.

Por que o Outlook na web só deixa salvar o anexo?

Esta é a causa mais comum e a menos conhecida, e muita gente culpa o Gmail, que não tem nada com isso.

A Microsoft mantém uma política de caixa de correio que controla o que o Outlook na web faz com cada tipo de anexo. Um dos parâmetros dessa política, o ForceSaveFileTypes, é descrito na documentação como "the attachment file types (file extensions) that can only be saved from Outlook on the web (not opened)".

.htm e .html estão entre os valores padrão dessa lista. O mesmo vale para o tipo MIME text/html, que aparece nos valores padrão do parâmetro irmão ForceSaveMimeTypes.

Traduzindo: se o seu cliente usa Outlook no navegador, que é o caso da maioria das empresas com Microsoft 365, o botão de abrir o seu anexo não existe para ele. Só o de baixar. E depois de baixar, ele precisaria saber que tem de arrastar o arquivo para dentro do navegador. A maioria não sabe, e não deveria precisar saber.

Para comparação, a lista de tipos que a mesma política permite abrir por padrão inclui .pdf, .doc, .docx, .xls, .xlsx, .ppt, .pptx, .txt, .rtf, .png, .jpg, .gif e .zip. HTML ficou de fora, e é o único formato de documento comum que ficou.

Ressalva honesta: esses são os valores padrão documentados. Um administrador de TI pode alterá-los. Se um cliente seu conseguiu abrir e outro não, é provavelmente isso.

O Gmail bloqueia anexos .html?

Não. Vale corrigir, porque o mito circula muito.

O Google publica a lista completa de extensões bloqueadas no Gmail. Ela tem dezenas de itens, entre eles .exe, .bat, .js, .jar e .msi, e .html e .htm não estão nela.

A confusão nasce de uma extensão parecida que está na lista: .hta. Não é a mesma coisa. .hta é HTML Application, um formato executável do Windows. Três letras de diferença, comportamento completamente diferente.

O que existe é a possibilidade de o administrador do Google Workspace de uma empresa configurar bloqueio ou aviso para tipos de arquivo incomuns. Mas isso é escolha da empresa do seu cliente, não comportamento padrão do Gmail.

Por que os aplicativos se recusam a renderizar HTML de terceiros?

Porque HTML não é um documento passivo. É código que executa.

Um arquivo .html pode conter JavaScript. Se um aplicativo renderizasse esse arquivo dentro do próprio endereço, o mesmo domínio onde você está logado, o código do arquivo passaria a rodar com a sua identidade de usuário logado. Ele poderia ler dados da sua sessão e agir como se fosse você.

O mecanismo que separa um site do outro se chama same-origin policy, e o MDN o define como o mecanismo de segurança que restringe como um documento ou script carregado de uma origem interage com um recurso de outra origem.

Quando conteúdo enviado por um usuário é servido dentro da origem do próprio aplicativo, o resultado tem nome: stored XSS, ou cross-site scripting armazenado. A descrição da OWASP explica o efeito: como o navegador acredita que o script veio de uma fonte confiável, ele consegue acessar cookies, tokens de sessão e outras informações guardadas para aquele site.

O próprio Google publicou o guia de como resolver isso, e a solução é servir conteúdo ativo de terceiros em um domínio separado e isolado, adicionado à lista pública de sufixos, do tipo product.usercontent.google.com.

Ou seja: exibir HTML de terceiros com segurança é trabalho de infraestrutura, não uma caixinha de configuração. Por isso o Outlook, o WhatsApp e os visualizadores de anexo simplesmente não fazem, e não vão passar a fazer.

E o Google Drive, que já hospedou HTML?

Hospedou até 2016, e parou. O anúncio saiu em 31 de agosto de 2015, com desligamento efetivo em 31 de agosto de 2016, quando o endereço googledrive.com/host/{id} deixou de servir conteúdo.

Um detalhe que os tutoriais erram: o motivo declarado pelo Google não foi segurança. O texto do anúncio diz que surgiu uma grande variedade de serviços de hospedagem web e que existem opções melhores hoje. Se você leu que o Drive tirou o recurso por causa de vírus ou phishing, isso não está na fonte primária.

O resultado prático é o mesmo: subir um .html no Drive e compartilhar o link não entrega uma página, entrega uma tela de visualização de arquivo. O que acontece em cada nuvem corporativa está em hospedar HTML no Google Drive.

Então como enviar o HTML do jeito certo?

Três caminhos, para situações diferentes.

1. Converter para PDF. Funciona em todo lugar e é o mais rápido. O custo é perder o que é interativo e perder a possibilidade de corrigir depois de enviar. Quando compensa e quando não compensa está em HTML ou PDF para o cliente.

2. Publicar em um servidor. GitHub Pages, Netlify, Vercel e Cloudflare Pages hospedam HTML estático de graça e entregam um endereço público de verdade. É a melhor opção se você já usa Git e linha de comando. Para quem não é desenvolvedor, o caminho até o primeiro link costuma ser longo demais para valer por uma proposta. As diferenças entre eles, incluindo a restrição de uso comercial que quase nenhum comparativo menciona, estão em onde hospedar HTML de graça.

3. Usar uma plataforma que transforma o arquivo em link. Você envia o .html e recebe um endereço. O cliente clica e vê a página no navegador dele, que é, afinal, o único programa que sabe renderizar HTML. É o que a I LOVE HTML faz, com endereço personalizado, senha, data de validade e registro de quem abriu, e é também o que fazem Tiiny Host, Static.app e HTMLy, entre outras.

O que separa as opções dessa categoria não é colocar a página no ar, que todas fazem, e sim o que vem depois: se dá para trocar o conteúdo sem trocar o link, se dá para exigir senha, e se você fica sabendo que a pessoa abriu. A separação entre os dois problemas está em hospedar não é compartilhar.

Quando não usar uma plataforma

Vale dizer com todas as letras: se o documento vai ser assinado, arquivado ou anexado a um processo, mande PDF. Link é bom para ser lido, PDF é bom para ser guardado. E se o conteúdo tem dado sensível de cliente, verifique quem consegue acessar o endereço antes de enviar, porque link sem senha é público para quem o receber. A lista completa das situações em que o formato não serve está em quando não usar a plataforma.

O que não conseguimos verificar

Este guia separa o que está documentado do que não está. Estes pontos ficam abertos, e vão continuar marcados como abertos até existir fonte primária:

• O que exatamente acontece ao abrir um .html no Android. A documentação descreve o mecanismo de intents, em que o sistema procura um app registrado para aquele tipo de arquivo, e avisa que pode não haver nenhum. Não há fonte oficial dizendo "abre no navegador" nem "dá erro".
• O comportamento no iPhone. A Apple documenta que HTML conforma a public.text e que o Quick Look pré-visualiza arquivos desse tipo. Ela não documenta se renderiza a página ou mostra o código.
• A lista de tipos de documento aceitos pelo WhatsApp. Não existe na documentação oficial. Só está publicado o limite de tamanho.

Perguntas frequentes

O arquivo HTML abre certo no meu computador. Por que quebra no do cliente?

Porque no seu computador ele abre no navegador, e no do cliente ele abre dentro do e-mail ou do gerenciador de arquivos. O arquivo é o mesmo; o programa que tenta interpretá-lo é diferente.

Juntar o CSS dentro do HTML resolve?

Resolve um problema diferente, o de estilos que somem quando você manda o .html sem os arquivos .css que o acompanham. Não resolve a recusa em renderizar: se o Outlook na web só deixa salvar, ele vai só deixar salvar independentemente de onde o CSS está.

Compactar em .zip ajuda?

Piora, e não pelo motivo que costumam dar. O .zip está entre os tipos que o Outlook na web permite abrir por padrão, então não é o cliente de e-mail que atrapalha. O problema é o destinatário: ele precisa descompactar, achar o arquivo certo dentro da pasta e abri-lo no navegador. São três passos a mais para alguém que já travou no primeiro.

Renomear o arquivo para .txt e pedir para o cliente renomear de volta?

Funciona tecnicamente e falha na prática. Você está transferindo trabalho técnico para quem contratou você justamente para não fazer trabalho técnico.

Vale mandar o arquivo e o link na mesma mensagem?

Vale, e é o que costuma funcionar melhor em proposta de valor alto: o link no corpo da mensagem, para ler, e o PDF anexado, para guardar. O anexo .html não entra nessa combinação, porque não funciona em nenhum dos dois papéis.

---

Fontes: Microsoft Learn, Set-OwaMailboxPolicy, Google, tipos de arquivo bloqueados no Gmail, MDN, same-origin policy, OWASP, Cross-Site Scripting, web.dev, Securely hosting user data e Google Workspace Updates, Deprecating web hosting support in Google Drive. Este guia trata de política de produto de terceiro e é revisado a cada seis meses.