// FERRAMENTA GRÁTIS · VISUALIZADOR HTML
Visualizador HTML
Abra um arquivo .html ou cole o código e veja o resultado aqui mesmo: em um quadro isolado, na largura de celular, tablet ou desktop, com tudo que vai se comportar mal listado por número de linha. Grátis, na hora, sem cadastro, e o arquivo nunca sai do seu navegador.
Também emEnglishDeutschEspañolFrançais日本語한국어Português (Brasil)繁體中文
Arraste um arquivo .html para qualquer ponto desta caixa, ou escolha um. Ele é lido com FileReader, nesta aba, e não vai adiante.
A renderização segue o que você digita com um terço de segundo de atraso. As observações atualizam na hora.
Um quadro isolado com scripts permitidos e sem acesso à mesma origem, para que o código rode sem encostar nesta página. Escolha uma largura para ver o layout que um celular ou um tablet teria.
Como visualizar um arquivo HTML no navegador
Três passos, e nenhum deles envia nada. O renderizador e as observações são um único script desta página, então tudo funciona até com a rede desligada.
- Abra o código. Arraste o arquivo .html para a caixa, use o seletor de arquivos ou cole a marcação direto. Os arquivos são lidos com a API FileReader do navegador, então nada é transferido para lugar nenhum.
- Olhe, e depois olhe estreito. A renderização aparece em um quadro isolado. Mude para 360 px para um celular e 768 px para um tablet: a mesma marcação, nas larguras em que os layouts costumam desmontar.
- Leia as observações abaixo. Cada observação traz a linha de onde veio: referências que o quadro não alcança, uma imagem em http que uma página segura descarta, um viewport ausente que faz a prévia estreita mentir para você.
Como este visualizador renderiza o seu arquivo
A marcação vai direto para um iframe por srcdoc, com sandbox="allow-scripts" e deliberadamente sem allow-same-origin. Na prática isso são três coisas. Seus scripts rodam, então uma página que se monta sozinha ao carregar realmente se monta. O quadro fica em uma origem opaca própria, então nada lá dentro consegue ler esta página, o armazenamento dela ou seus cookies. E o CSS, as fontes e as imagens vindas de hosts públicos carregam normalmente, então uma página construída sobre um CDN fica com a cara que um visitante vai ver.
Duas categorias de propósito não resolvem, e as observações dizem isso em vez de deixar você adivinhando. Referências a arquivos vizinhos do original — estilo.css, img/topo.png — não têm pasta contra a qual resolver dentro do quadro. Referências ao seu próprio sistema de arquivos não carregam em nenhuma aba de nenhum navegador; essa restrição é do navegador, não nossa. Se o layout parecer sem estilo, leia as observações antes de sair caçando no CSS.
Seu leitor está no celular, e o link vai chegar pelo WhatsApp
Aqui a prévia estreita não é um caso extremo: é a visão principal. A maior parte do acesso à web no Brasil acontece em celular Android de tela estreita, muitas vezes em rede móvel instável. Se você só olhar a página em largura cheia, está olhando a minoria dos seus leitores. Por isso vale começar pelo botão de 360 px e só depois abrir para a largura cheia — a ordem inversa da que quase todo mundo usa.
Duas consequências práticas aparecem nas observações abaixo do quadro:
- Sem
<meta name="viewport">, o celular não usa 360 pixels CSS. Ele monta a página por volta de 980 e depois reduz tudo para caber, o que deixa o texto pequeno demais para ler e faz seus estilos de celular nunca dispararem. A prévia estreita só é honesta quando essa tag existe. - Cada host externo é mais uma conexão em uma rede lenta. A observação que lista os hosts de onde a página puxa scripts, estilos e fontes é, na prática, a sua lista de dependências de carregamento. Em Wi-Fi de escritório ninguém percebe; em 4G no ônibus, cada um deles é mais uma espera antes de o texto aparecer. Fontes hospedadas junto da própria página resolvem boa parte disso.
E tem a parte que a renderização não mostra: como o link vai aparecer quando alguém colar no WhatsApp. Esse cartão não vem da página renderizada, vem do <head>. O robô que monta a prévia baixa o HTML, lê as tags og:title, og:description e og:image e vai embora — ele não executa JavaScript. Duas conclusões que valem o tempo: uma página que se monta inteiramente no navegador não tem cartão nenhum, por mais bonita que esteja aqui em cima; e a og:image precisa ser uma URL absoluta em https, acessível sem login e de tamanho modesto, senão o cartão sai só com texto.
O limite honesto: esta ferramenta não busca nem desenha o cartão do WhatsApp. Ela avisa quando og:image, <title> ou a meta description estão faltando, com o número da linha, e para por aí. Conferir o cartão de verdade só depois que a página tiver um endereço público — que é exatamente o passo seguinte.
Ver a página na largura do celular
A maioria dos visualizadores dá uma coluna com a largura que a janela tiver. Este dá três ao quadro: 360 px, mais ou menos um celular em pé; 768 px, um tablet pequeno; e cheia, o que a coluna permitir. O quadro é um contexto de navegação de verdade, então media queries, container queries e a quebra do flexbox respondem à largura que você escolher, e não à do seu monitor.
Vale conferir três coisas na largura estreita, porque são as que mais aparecem: tabelas largas que empurram a página para os lados e criam barra de rolagem horizontal; imagens sem max-width: 100%, que fazem a mesma coisa; e botões com largura fixa em pixels, que param de caber assim que o texto em português cresce em relação ao original em inglês. Nenhuma dessas três dá para ver em largura cheia.
As observações abaixo do quadro, e por que um visualizador normalmente não tem nenhuma
Renderizar responde «está com a cara certa». Não responde «vai continuar com a cara certa em outro lugar», e é aí que moram quase todas as surpresas. Por isso cada observação está amarrada a um número de linha e a uma consequência concreta:
- Uma imagem em
http://é descartada por qualquer página segura. Se o exemplo estiver carregado, você está vendo uma agora: o logotipo falta acima e a observação aponta a linha. - Um caminho para o seu próprio disco aparece na sua máquina e em nenhuma outra. Dentro deste quadro isolado também não aparece, o que é uma prévia justa da experiência de todo mundo.
- Um
<!DOCTYPE html>faltando coloca o navegador em modo quirks, onde o cálculo das caixas e as alturas de linha herdadas seguem regras anteriores a 2001. Aí a prévia acima deixa de ser prévia de algo que você queira. - Um módulo em vez de um documento — código que começa com
importouexport default— não é renderizável. Melhor ouvir isso do que encarar um quadro em branco.
Se o arquivo vai para um endereço de verdade e não só para uma olhada, a página de hospedar um arquivo HTML roda as mesmas verificações e segue com os dois comandos que publicam a pasta.
// Perguntas frequentes
Como visualizar um arquivo HTML sem enviar para nenhum site?
Use um visualizador que leia o arquivo localmente. Nesta página ele é lido com a API FileReader do navegador e renderizado em um iframe isolado da mesma aba, então o conteúdo nunca chega a um servidor. Você também pode dar dois cliques no arquivo e abrir no navegador; a diferença é que esta página ainda diz quais partes vão se comportar de outro jeito quando o arquivo não estiver mais no seu disco.
Dá para ver como a página fica no celular?
Dá: coloque o quadro em 360 px para celular ou 768 px para tablet. As media queries respondem à largura do quadro, então o layout que você vê é o layout naquela largura. Um detalhe: se o arquivo não tiver a tag viewport, um celular de verdade não usa 360 pixels CSS e a prévia estreita fica melhor do que a realidade. As observações avisam nesse caso.
Por que meu link não gera prévia no WhatsApp?
Porque o cartão não vem da página renderizada e sim do head. O robô que monta a prévia baixa o HTML, lê og:title, og:description e og:image e vai embora, sem executar JavaScript. Uma página que se monta toda no navegador não tem cartão, e a og:image precisa ser uma URL absoluta em https acessível sem login. Esta ferramenta apenas avisa quando essas tags faltam; ela não desenha o cartão.
Por que meu CSS ou minhas imagens não aparecem na prévia?
Porque o quadro não tem pasta contra a qual resolver caminhos relativos. Uma referência como estilo.css ou img/topo.png aponta para um arquivo que está ao lado do original, e o navegador não alcança isso de dentro de um quadro srcdoc. Folhas de estilo e imagens servidas de uma URL https aparecem normalmente. As observações listam cada referência que não resolveu, com a linha.
É seguro colar HTML com scripts neste visualizador?
O quadro executa scripts de propósito, porque senão uma página que se monta ao carregar não mostraria nada. Ele é isolado e sem acesso à mesma origem, então o código lá dentro não lê esta página, nem o armazenamento, nem os cookies, e não navega a aba. Ele ainda pode fazer requisições a hosts públicos, exatamente como em uma aba comum, então trate marcação desconhecida com o cuidado de sempre.
Este visualizador HTML funciona offline?
Funciona. É tudo um script só na página, sem chamadas de rede próprias. Depois que a página carregar, você pode desconectar e continuar abrindo arquivos. Marcação que busca scripts ou fontes em um CDN vai, claro, renderizar sem eles.
Como transformo o que estou vendo em uma página que os outros abrem?
Salve como index.html dentro de uma pasta e publique essa pasta: clize claim seunome garante o handle grátis seunome.clize.app, e clize deploy ./pasta --domain seunome.clize.app coloca no ar por HTTPS. Não há editor para onde migrar nem etapa de exportação — os bytes que você viu são os bytes servidos.
Agora dê a ela uma URL que outra pessoa possa abrir.
A renderização acima vive só na sua aba. Dois comandos transformam o mesmo arquivo em um endereço HTTPS que dá para colar em uma mensagem — handle grátis, certificado automático, quantos deploys você quiser.
$ npm i -g @clize/clize && clize login $ clize claim seunome $ clize deploy ./pasta --domain seunome.clize.app[ Sites by Clize → ]