// HERRAMIENTA GRATIS · VISOR HTML
Visor HTML
Abre un archivo .html o pega el código y míralo pintado aquí mismo: en un marco aislado, a anchura de móvil, tableta o escritorio, y con todo lo que se va a portar mal listado por número de línea. Gratis, al instante, sin registro, y el archivo no sale de tu navegador.
También enEnglishDeutschEspañolFrançais日本語한국어Português (Brasil)繁體中文
Arrastra un archivo .html a cualquier parte de esta caja, o elígelo. Se lee con FileReader, en esta pestaña, y de aquí no pasa.
El pintado sigue a lo que escribes con un tercio de segundo de retraso. Las notas se actualizan al momento.
Un marco aislado con scripts permitidos y sin acceso al mismo origen, para que el código pueda ejecutarse sin tocar esta página. Elige una anchura para ver el diseño que tendría un móvil o una tableta.
Cómo ver un archivo HTML en el navegador
Tres pasos y en ninguno se sube nada. El motor de pintado y las notas son un único script de esta página, así que también funciona con la red desconectada.
- Abre el código. Arrastra el archivo .html sobre la caja, usa el selector de archivos o pega el marcado directamente. Los archivos se leen con la API FileReader del navegador, así que no se transfiere nada a ninguna parte.
- Míralo, y después míralo estrecho. El resultado aparece en un marco aislado. Cámbialo a 360 px para un móvil y a 768 px para una tableta: el mismo código, en las anchuras donde los diseños suelen romperse.
- Lee las notas de debajo. Cada nota lleva la línea de la que viene: referencias a las que el marco no llega, una imagen cargada por http que una página segura descarta, un viewport ausente que hace que la vista estrecha te mienta.
Cómo pinta tu archivo este visor
El marcado entra directo en un iframe a través de srcdoc, con sandbox="allow-scripts" y a propósito sin allow-same-origin. En la práctica eso son tres cosas. Tus scripts se ejecutan, así que una página que se construye sola al cargar se construye de verdad. El marco vive en su propio origen opaco, así que nada de lo que hay dentro puede leer esta página, su almacenamiento ni sus cookies. Y el CSS, las tipografías y las imágenes que vengan de servidores públicos cargan con normalidad, así que una página montada sobre un CDN se ve como la verá una visita.
Dos categorías no se resuelven a propósito, y las notas lo dicen en vez de dejarte adivinando. Las referencias a archivos que están junto al original —estilo.css, img/cabecera.png— no tienen carpeta contra la que resolverse dentro del marco. Las referencias a tu propio sistema de archivos no cargan en ninguna pestaña de ningún navegador; esa restricción es del navegador, no nuestra. Si el diseño se ve sin estilos, lee las notas antes de ponerte a bucear en el CSS.
Tildes, ñ y ¿ ¡ que salen como ñ y ¿
Es el primer susto de cualquiera que abra un HTML en español, y en un visor tiene una explicación concreta. Cuando eliges un archivo, se lee con FileReader.readAsText(), que siempre interpreta los bytes como UTF-8. Si el archivo se guardó en UTF-8, todo sale bien. Si se guardó en Windows-1252 o ISO-8859-1 —el Bloc de notas de siempre en modo ANSI, un «Guardar como página web» de Word, un archivo que arrastras desde un proyecto de hace quince años— cada carácter no inglés ocupa un byte que UTF-8 no sabe leer, y el resultado es el zoo conocido:
| Lo que escribiste | Lo que aparece | Byte de origen |
|---|---|---|
| ñ | ñ o � | 0xF1 en Windows-1252 |
| é | é | 0xE9 |
| ¿ | ¿ | 0xBF |
| « » | « » | 0xAB y 0xBB |
Lo desconcertante es que al hacer doble clic en el mismo archivo se ve perfecto. No es magia: cuando el navegador abre un archivo él mismo, mira los bytes y la etiqueta <meta charset> y decide la codificación. FileReader no hace nada de eso. Así que un archivo que se ve bien en tu escritorio y mal aquí casi siempre te está diciendo la verdad sobre un problema que tienes: en cuanto lo sirva un servidor que anuncie charset=utf-8, tus visitas verán exactamente esto.
Se arregla convirtiendo el archivo una vez y dejándolo así: iconv -f WINDOWS-1252 -t UTF-8 pagina.html > pagina-utf8.html, o «Guardar como → UTF-8» en cualquier editor decente. Después asegúrate de que la primera línea del <head> es <meta charset="utf-8">, porque sin ella cada intermediario vuelve a adivinar.
Un límite honesto de esta herramienta: no detecta la codificación real de tu archivo. Solo comprueba si hay una etiqueta charset declarada y te avisa cuando falta. El diagnóstico de arriba lo haces tú mirando el marco; nosotros no podemos hacerlo por ti, y preferimos decirlo a fingir lo contrario.
Ver la página a anchura de móvil
Casi todos los visores te dan una columna con la anchura que tenga la ventana. Este le da tres al marco: 360 px, más o menos un móvil en vertical; 768 px, una tableta pequeña; y completo, lo que dé la columna. El marco es un contexto de navegación real, así que las media queries, las container queries y el ajuste de flexbox responden a la anchura que elijas y no a la de tu monitor.
Un aviso que las notas te dan solas: sin <meta name="viewport" content="width=device-width, initial-scale=1">, un móvil no pinta a 360 píxeles CSS. Maqueta a unos 980 y encoge el resultado, así que el texto queda diminuto y tus estilos móviles nunca llegan a activarse. La vista estrecha solo es honesta cuando esa etiqueta está presente, que es justo por lo que aparece señalada bajo el marco.
Las notas bajo el marco, y por qué un visor normalmente no tiene ninguna
Pintar responde a «¿se ve bien?». No puede responder a «¿se seguirá viendo bien en otro sitio?», y ahí es donde vive la mayoría de las sorpresas. Por eso cada nota está atada a un número de línea y a una consecuencia concreta:
- Una imagen por
http://la descarta cualquier página segura. Si has cargado el ejemplo estás viendo una ahora mismo: falta el logotipo arriba y la nota apunta a la línea. - Una ruta a tu propio disco se pinta en tu máquina y en ninguna otra. Dentro de este marco aislado tampoco se pinta, que es una vista previa justa de la experiencia de los demás.
- Un
<!DOCTYPE html>ausente mete al navegador en modo quirks, donde el modelo de caja y las alturas de línea heredadas siguen reglas anteriores a 2001. Lo de arriba deja entonces de ser una vista previa de nada que quieras. - Un módulo en vez de un documento —código que empieza por
importoexport default— no se puede pintar. Mejor que te lo digan a que te quedes mirando un marco en blanco.
Si el archivo va camino de una dirección real y no de un vistazo rápido, la página de subir un archivo HTML a internet hace las mismas comprobaciones y sigue con los dos comandos que publican la carpeta.
// Preguntas frecuentes
¿Cómo veo un archivo HTML sin subirlo a ningún sitio?
Usa un visor que lea el archivo en local. En esta página se lee con la API FileReader del navegador y se pinta en un iframe aislado de la misma pestaña, así que el contenido nunca llega a un servidor. También puedes hacer doble clic en el archivo y abrirlo en tu navegador; la diferencia es que esta página además te dice qué partes se comportarán de otra manera cuando el archivo deje de estar en tu disco.
¿Por qué se ven mal las tildes y la ñ en el visor?
Porque FileReader interpreta siempre los bytes como UTF-8 y tu archivo seguramente está guardado en Windows-1252 o ISO-8859-1. Por eso la ñ sale como ñ y el ¿ como ¿. Al hacer doble clic en el archivo se ve bien porque ahí el navegador mira los bytes y la etiqueta meta charset. Conviértelo una vez con iconv -f WINDOWS-1252 -t UTF-8 y deja escrito meta charset utf-8 en el head.
¿El visor detecta la codificación de mi archivo?
No, y es mejor decirlo claro: solo comprueba si hay una etiqueta charset declarada y avisa cuando falta. La codificación real de los bytes no se adivina aquí. Si el texto sale con caracteres raros en el marco, eso es el diagnóstico, y el arreglo es convertir el archivo a UTF-8 antes de seguir.
¿Por qué no aparecen mi CSS o mis imágenes en la vista previa?
Porque el marco no tiene carpeta contra la que resolver rutas relativas. Una referencia como estilo.css o img/cabecera.png apunta a un archivo que está junto al original, y el navegador no puede alcanzarlo desde un marco srcdoc. Las hojas de estilo y las imágenes servidas desde una URL https sí aparecen. Las notas de debajo listan cada referencia que no se pudo resolver, con su línea.
¿Puedo previsualizar cómo se ve la página en un móvil?
Sí: pon el marco a 360 px para un móvil o a 768 px para una tableta. Las media queries responden a la anchura del marco, así que el diseño que ves es el diseño a esa anchura. Un matiz: si el archivo no tiene etiqueta viewport, un móvil real no usará 360 píxeles CSS y la vista estrecha se verá mejor que la realidad. Las notas avisan de ese caso.
¿Este visor HTML funciona sin conexión?
Sí. Todo es un único script en la página, sin llamadas de red propias. Una vez cargada puedes desconectarte y seguir abriendo archivos. El código que traiga sus scripts o sus tipografías de un CDN se pintará, claro, sin ellos.
¿Cómo convierto lo que estoy viendo en una página que otros puedan abrir?
Guárdalo como index.html dentro de una carpeta y publica esa carpeta: clize claim tunombre reserva el handle gratuito tunombre.clize.app y clize deploy ./carpeta --domain tunombre.clize.app lo pone en línea por HTTPS. No hay editor al que mudarse ni paso de exportación: los bytes que has visto son los bytes que se sirven.
Ahora dale una URL que pueda abrir otra persona.
Lo que ves arriba vive solo en tu pestaña. Dos comandos convierten ese mismo archivo en una dirección HTTPS que puedes pegar en un mensaje: handle gratis, certificado automático y tantos despliegues como quieras.
$ npm i -g @clize/clize && clize login $ clize claim tunombre $ clize deploy ./carpeta --domain tunombre.clize.app[ Sites by Clize → ]