Visualização HTML / Editor de código

Escreva HTML, CSS e JavaScript nos editores abaixo e veja o resultado instantaneamente no painel de pré-visualização.

Pré-visualização

Como funciona

  1. Cole ou digite HTML : insira seu código HTML (documentos completos, fragmentos, templates ou HTML de e-mail) no editor.
  2. Veja a renderização em tempo real : o painel de pré-visualização mostra exatamente como o navegador renderiza seu HTML em tempo real.
  3. Itere rapidamente : edite e pré-visualize em um ciclo curto sem trocar de aba ou salvar arquivo.

Por que usar a pré-visualização HTML ?

Ao escrever HTML para templates, e-mails, componentes ou páginas estáticas, você precisa de feedback constante sobre a renderização da marcação. Abrir arquivos em um navegador e atualizar manualmente quebra seu fluxo. Esta ferramenta de pré-visualização HTML renderiza seu HTML instantaneamente enquanto você digita, oferecendo uma visão visual em tempo real na mesma janela, ideal para iterar rapidamente em templates, depurar problemas de layout e testar e-mails HTML antes do envio.

Funcionalidades

Perguntas frequentes

Posso pré-visualizar e-mails HTML ?

Sim. Cole seu HTML de e-mail, incluindo estilos inline e layouts em tabelas. A pré-visualização renderiza exatamente como um cliente de e-mail faria. Observe que fontes externas e certos recursos CSS podem se comportar de forma diferente em clientes de e-mail reais.

O CSS e o JavaScript externos funcionam ?

Folhas de estilo externas carregadas via tags <link> podem não carregar devido a restrições CORS na pré-visualização em sandbox. A execução JavaScript é limitada pelo sandbox. Para melhores resultados, use CSS inline. Recursos externos vindos de CDNs que permitem acesso cross-origin serão carregados normalmente.

Posso usá-la para testar designs responsivos ?

Sim. Arraste a largura do painel de pré-visualização para simular diferentes tamanhos de tela, ou use as predefinições de viewport (celular, tablet, desktop) para testar seus breakpoints responsivos.

Como funciona a prévia ao vivo: iframe srcdoc

O elemento <iframe> foi introduzido no HTML 4.0 (dezembro de 1997) para incorporar um documento dentro de outro. Por duas décadas, a única maneira de popular um iframe era através do atributo src apontando para uma URL. O atributo srcdoc, permitindo passar o HTML do iframe inline como string, foi adicionado no HTML5 (W3C Rec, outubro de 2014) e agora é suportado por todo navegador moderno. srcdoc é o que torna possível uma ferramenta de prévia HTML baseada em navegador sem upload para servidor: você escreve HTML, a ferramenta envolve em <iframe srcdoc="...">, o navegador renderiza em um contexto isolado, e nada atravessa a rede.

O atributo sandbox e a armadilha do same-origin

<iframe sandbox> foi introduzido no HTML5 para aplicar uma política de segurança por iframe. Com nenhum valor, a sandbox mais restritiva se aplica: same-origin restrito (tratado como origem única), scripts desativados, formulários desativados, navegação de nível superior desativada, plugins desativados, bloqueio de ponteiro desativado, popups desativados, reprodução automática de mídia desativada. Você ativa de volta adicionando tokens: sandbox="allow-scripts", allow-forms, allow-popups, allow-top-navigation, etc. Cada token abre uma capacidade específica.

A combinação para nunca usar é sandbox="allow-scripts allow-same-origin" simultaneamente: isso permite que o JavaScript chame document.domain e suba até a janela pai, derrotando completamente a sandbox. Os navegadores avisam sobre isso nas DevTools quando você define ambos. Esta ferramenta de prévia define allow-scripts e explicitamente NÃO allow-same-origin, então o JS do usuário roda mas não pode ler ou escrever o DOM da página pai, cookies, localStorage, IndexedDB, ou caches de service-worker.

Content Security Policy, a segunda linha de defesa

Uma defesa separada mas relacionada é Content-Security-Policy, um cabeçalho de resposta HTTP introduzido no W3C CSP Level 1 (Candidate Recommendation, novembro de 2012). CSP Level 3 é o padrão atual. A diretiva-chave para ferramentas de prévia: frame-src (quais iframes podem ser carregados) e script-src (quais scripts inline/externos podem rodar). Mesmo que um payload malicioso escapasse da sandbox, o CSP da página hospedeira ainda se aplicaria e proibiria a maioria dos caminhos de exfiltração. Defesa em profundidade: a sandbox isola o código do iframe, e o CSP do host limita o que a página hospedeira pode fazer se o iframe a tivesse influenciado de alguma forma.

HTML de cliente de e-mail é um mundo próprio

Uma prévia que renderiza HTML de navegador moderno não renderiza HTML de e-mail. Os principais clientes de e-mail usam motores muito diferentes: Gmail web usa um renderizador baseado em WebKit com remoção de classes e suporte limitado para tags <style> (adicionado em 2016). Apple Mail / iOS Mail usam WebKit, o renderizador mais permissivo. Outlook desktop (2007 a 2019) renderiza HTML de e-mail através do motor de renderização Microsoft Word: sem suporte a bloco <style>, sem flex/grid, sem elementos posicionados, sem animações; imagens de fundo precisam de comentários condicionais VML. Esta peculiaridade do Outlook é o maior problema no desenvolvimento de e-mail. Outlook 365 web é WebKit moderno. O «novo Outlook» implantado em 2023-2024 usa Edge WebView2. Para prévias reais de cliente de e-mail, use um serviço pago como Litmus ou Email on Acid.

Breakpoints responsivos para testar

As convenções de breakpoints CSS media-query remontam ao artigo «Responsive Web Design» de Ethan Marcotte em maio de 2010 em A List Apart. Os dois frameworks dominantes escolheram cortes diferentes:

A linhagem de padrões HTML

Referência rápida para os padrões contra os quais sua prévia está renderizando: HTML 2.0 (RFC 1866, novembro de 1995), a primeira especificação oficial de Tim Berners-Lee, estabeleceu o conjunto básico de tags. HTML 4.01 (W3C Rec, dezembro de 1999) adicionou <script>, <style>, <table>, frames. XHTML 1.0 (W3C Rec, janeiro de 2000) tentou uma serialização XML estrita, em sua maioria abandonada até 2010. HTML5 (W3C Rec, outubro de 2014) adicionou elementos semânticos (<article>, <section>, <nav>), canvas, video/audio, web storage. Em maio de 2019, WHATWG assumiu a administração do W3C, e HTML agora é mantido como Living Standard em html.spec.whatwg.org, atualizado continuamente.

Casos de uso comuns

Erros comuns

  1. Tentar ler o conteúdo do iframe a partir do pai. Com sandbox definido, restrições cross-origin bloqueiam. O iframe pode fazer postMessage de saída, mas o pai não pode alcançar para dentro.
  2. Colar CSS que mira body e ficar surpreso que os estilos body da ferramenta não sejam afetados. O iframe é um documento separado com seu próprio DOM.
  3. Recursos externos bloqueados por CSP. Um <img src="https://example.com/x.png"> pode carregar bem na sua prévia mas ser bloqueado quando você copia o mesmo código para um site de produção bloqueado por CSP.
  4. Esquecer que DOMContentLoaded dispara no iframe, não no pai. Scripts dentro do iframe veem seu próprio document, não o da ferramenta.
  5. Definir tanto allow-scripts quanto allow-same-origin em uma ferramenta sandbox, derrotando completamente o propósito. Navegadores avisam sobre essa combinação nas DevTools.

Mais perguntas frequentes

Por que meu localStorage não funciona na prévia?

localStorage e sessionStorage requerem allow-same-origin no atributo sandbox. Como combinar isso com allow-scripts derrotaria a sandbox, esta prévia bloqueia armazenamento por design. Seu código lançará um SecurityError no primeiro localStorage.setItem. Para testar código dependente de armazenamento, execute-o em uma origem real (um servidor de dev local, por exemplo).

Qual versão de JavaScript a prévia suporta?

Qualquer versão que seu navegador suporte. O iframe roda o mesmo motor JS que a página pai, então um usuário Chrome obtém V8, um usuário Firefox obtém SpiderMonkey, um usuário Safari obtém JavaScriptCore. Recursos modernos (optional chaining, top-level await, classes, async/await, sintaxe ES2024) funcionam se seu navegador os suportar. Para testes com alvo de navegadores mais antigos, cole saída transpilada de Babel ou swc.

Posso carregar scripts e folhas de estilo externos?

Sim para a maioria dos CDNs públicos. <script src="https://cdn.jsdelivr.net/..."> e <link href="https://cdn.tailwindcss.com" rel="stylesheet"> geralmente funcionam porque esses CDNs definem cabeçalhos CORS permissivos. Recursos que exigem credenciais ou são bloqueados por origem falharão. O painel Network nas DevTools do seu navegador mostra exatamente quais recursos carregaram e quais foram bloqueados.

Em que isso difere de CodePen / JSFiddle / StackBlitz?

Esses são serviços completos de hospedagem de código com funcionalidades de salvar / compartilhar / fork / colaboração e requerem contas. Esta ferramenta é um rascunho de página única: sem conta, sem salvamento, sem compartilhamento, sem analytics. Cole, previsualize, itere, feche a aba. Para algo que você queira manter ou compartilhar, CodePen ainda é a melhor opção.

Meu código é enviado a algum lugar?

Não. O HTML / CSS / JS que você cola é envolvido em <iframe srcdoc="..."> na mesma página e renderiza em uma origem única em sandbox no seu navegador. Nenhuma chamada de rede transporta seu conteúdo. Recursos externos que seu HTML referencia (imagens, scripts, folhas de estilo) são obtidos pelo seu navegador da mesma forma que seriam em qualquer página web, mas o código-fonte em si nunca deixa a página.

Ferramentas relacionadas

Conversor de código para imagem Minificador de HTML Visualizador gratuito de Markdown on-line Gerador de tabelas HTML