Vista previa HTML / Editor de código
Escribe HTML, CSS y JavaScript en los editores de abajo y visualiza el resultado al instante en el panel de vista previa.
Cómo funciona
- Pega o escribe HTML: introduce tu código HTML (documentos completos, fragmentos, plantillas o HTML de correo) en el editor.
- Visualiza el renderizado en directo: el panel de vista previa muestra exactamente cómo el navegador renderiza tu HTML en tiempo real.
- Itera con rapidez: edita y previsualiza en un bucle cerrado sin cambiar de pestaña ni guardar archivos.
¿Por qué usar la vista previa HTML?
Cuando escribes HTML para plantillas, correos, componentes o páginas estáticas, necesitas retroalimentación constante sobre el renderizado del marcado. Abrir archivos en un navegador y refrescar manualmente rompe tu flujo. Esta herramienta de vista previa HTML renderiza tu HTML al instante mientras escribes, ofreciendo una vista previa visual en directo en la misma ventana, ideal para iterar rápido sobre plantillas, depurar problemas de diseño y probar correos HTML antes de enviarlos.
Funcionalidades
- Renderizado en tiempo real: la vista previa se actualiza a medida que escribes, sin retraso ni refresco manual.
- Compatibilidad HTML completa: renderiza documentos completos con etiquetas <head>, <style> y <body>, o fragmentos HTML simples.
- Entorno aislado: la vista previa se ejecuta en un iframe en sandbox, impidiendo que los scripts afecten a la página.
- Vista previa responsiva: redimensiona el panel de vista previa para probar el renderizado HTML en distintos anchos de viewport.
- Visualización de errores: los errores HTML se registran para detectar etiquetas rotas y marcado inválido.
Preguntas frecuentes
¿Puedo previsualizar correos HTML?
Sí. Pega tu HTML de correo, incluidos los estilos en línea y los diseños en tablas. La vista previa renderiza exactamente como lo haría un cliente de correo. Ten en cuenta que las fuentes externas y algunas funciones CSS pueden comportarse de forma distinta en los clientes de correo reales.
¿Funcionan el CSS y el JavaScript externos?
Las hojas de estilo externas cargadas mediante etiquetas <link> pueden no cargarse por las restricciones CORS en la vista previa en sandbox. La ejecución de JavaScript está limitada por el sandbox. Para mejores resultados, usa CSS en línea. Los recursos externos de CDN que permiten el acceso cross-origin se cargarán con normalidad.
¿Puedo usarlo para probar diseños responsivos?
Sí. Arrastra el ancho del panel de vista previa para simular distintos tamaños de pantalla, o usa los preajustes de viewport (móvil, tableta, ordenador) para probar tus puntos de ruptura responsivos.
Cómo funciona la previsualización en vivo: iframe srcdoc
El elemento <iframe> se introdujo en HTML 4.0 (diciembre de 1997) para incrustar un documento dentro de otro. Durante dos décadas, la única forma de poblar un iframe era a través del atributo src apuntando a una URL. El atributo srcdoc, que te permite pasar el HTML del iframe en línea como una cadena, se añadió en HTML5 (W3C Rec, octubre de 2014) y ahora es compatible con todos los navegadores modernos. srcdoc es lo que hace posible una herramienta de previsualización HTML basada en navegador sin carga al servidor: escribes HTML, la herramienta lo envuelve en <iframe srcdoc="...">, el navegador lo renderiza en un contexto aislado, y nada cruza la red.
El atributo sandbox y la trampa del same-origin
<iframe sandbox> se introdujo en HTML5 para aplicar una política de seguridad por iframe. Con sin valor, se aplica la sandbox más restrictiva: same-origin restringido (tratado como origen único), scripts deshabilitados, formularios deshabilitados, navegación de nivel superior deshabilitada, plugins deshabilitados, bloqueo de puntero deshabilitado, popups deshabilitados, reproducción automática de medios deshabilitada. Vuelves a habilitar añadiendo tokens: sandbox="allow-scripts", allow-forms, allow-popups, allow-top-navigation, etc. Cada token abre una capacidad específica.
La combinación a nunca usar es sandbox="allow-scripts allow-same-origin" simultáneamente: esto permite a JavaScript llamar document.domain y subir a la ventana padre, derrotando completamente la sandbox. Los navegadores advierten sobre esto en DevTools cuando estableces ambos. Esta herramienta de previsualización establece allow-scripts y explícitamente NO allow-same-origin, por lo que el JS del usuario se ejecuta pero no puede leer ni escribir el DOM de la página padre, cookies, localStorage, IndexedDB, o cachés de service-worker.
Content Security Policy, la segunda línea de defensa
Una defensa separada pero relacionada es Content-Security-Policy, un encabezado de respuesta HTTP introducido en W3C CSP Level 1 (Candidate Recommendation, noviembre de 2012). CSP Level 3 es el estándar actual. La directiva clave para herramientas de previsualización: frame-src (qué iframes se pueden cargar) y script-src (qué scripts inline/externos pueden ejecutarse). Incluso si una carga maliciosa escapara de la sandbox, el CSP de la página anfitriona aún aplicaría y prohibiría la mayoría de las rutas de exfiltración. Defensa en profundidad: la sandbox aísla el código del iframe, y el CSP del anfitrión limita lo que la página anfitriona puede hacer si el iframe la influyera de alguna manera.
El HTML de cliente de correo es su propio mundo
Una previsualización que renderiza HTML de navegador moderno no renderiza HTML de correo. Los principales clientes de correo usan motores muy diferentes: Gmail web usa un renderizador basado en WebKit con eliminación de clases y soporte limitado para etiquetas <style> (añadido en 2016). Apple Mail / iOS Mail usan WebKit, el renderizador más permisivo. Outlook desktop (2007 a 2019) renderiza HTML de correo a través del motor de renderizado de Microsoft Word: sin soporte de bloque <style>, sin flex/grid, sin elementos posicionados, sin animaciones; las imágenes de fondo necesitan comentarios condicionales VML. Esta rareza de Outlook es el mayor problema en el desarrollo de correo. Outlook 365 web es WebKit moderno. El «nuevo Outlook» desplegado en 2023-2024 usa Edge WebView2. Para previsualizaciones reales de clientes de correo, usa un servicio de pago como Litmus o Email on Acid.
Breakpoints responsivos a probar
Las convenciones de breakpoints CSS media-query se remontan al artículo «Responsive Web Design» de Ethan Marcotte de mayo de 2010 en A List Apart. Los dos frameworks dominantes eligieron cortes diferentes:
- Breakpoints Bootstrap 5 (desde la versión 4, octubre de 2016):
576px / 768px / 992px / 1200px / 1400pxpara sm / md / lg / xl / xxl. - Breakpoints Tailwind CSS:
640px / 768px / 1024px / 1280px / 1536pxpara sm / md / lg / xl / 2xl. - Anchos de dispositivos estándar: iPhone SE 375×667, iPhone 14/15 390×844, iPad 768×1024, iPad Air 820×1180, desktop 1280×800 / 1440×900 / 1920×1080, 4K 3840×2160.
La línea de estándares HTML
Referencia rápida para los estándares contra los que tu previsualización está renderizando: HTML 2.0 (RFC 1866, noviembre de 1995), la primera especificación oficial de Tim Berners-Lee, estableció el conjunto básico de etiquetas. HTML 4.01 (W3C Rec, diciembre de 1999) añadió <script>, <style>, <table>, frames. XHTML 1.0 (W3C Rec, enero de 2000) intentó una serialización XML estricta, mayormente abandonada hacia 2010. HTML5 (W3C Rec, octubre de 2014) añadió elementos semánticos (<article>, <section>, <nav>), canvas, video/audio, web storage. En mayo de 2019, WHATWG asumió la administración de W3C, y HTML ahora se mantiene como Living Standard en html.spec.whatwg.org, actualizado continuamente.
Casos de uso comunes
- Prototipado de plantillas de correo (sabiendo que el render del iframe no coincidirá con Outlook).
- Borrador rápido HTML / CSS cuando no quieres crear una cuenta de CodePen.
- Construcción de recetas de demo para artículos de blog o documentación.
- Enseñar HTML básico a estudiantes con retroalimentación visual instantánea.
- Visualización de algoritmos JS, combinando estructura HTML/CSS con pequeños scripts JS.
- Pruebas de comportamiento de formularios sin levantar un servidor.
- Experimentación con accesibilidad, probando atributos
aria-*, modelos de rol, orden de tabulación.
Errores comunes
- Intentar leer el contenido del iframe desde el padre. Con
sandboxestablecido, las restricciones cross-origin lo bloquean. El iframe puede hacerpostMessagesaliente, pero el padre no puede alcanzar adentro. - Pegar CSS que apunta a
bodyy sorprenderse de que los estilos body de la herramienta no se vean afectados. El iframe es un documento separado con su propio DOM. - Recursos externos bloqueados por CSP. Un
<img src="https://example.com/x.png">puede cargar bien en tu previsualización pero ser bloqueado cuando copias el mismo código a un sitio de producción bloqueado por CSP. - Olvidar que
DOMContentLoadedse dispara en el iframe, no en el padre. Los scripts dentro del iframe ven su propiodocument, no el de la herramienta. - Establecer ambos
allow-scriptsyallow-same-originen una herramienta sandbox, derrotando completamente el propósito. Los navegadores advierten sobre esta combinación en DevTools.
Más preguntas frecuentes
¿Por qué no funciona mi localStorage en la previsualización?
localStorage y sessionStorage requieren allow-same-origin en el atributo sandbox. Como combinar eso con allow-scripts derrotaría la sandbox, esta previsualización bloquea el almacenamiento por diseño. Tu código lanzará un SecurityError en el primer localStorage.setItem. Para probar código dependiente de almacenamiento, ejecútalo en un origen real (un servidor de desarrollo local, por ejemplo).
¿Qué versión de JavaScript soporta la previsualización?
Lo que tu navegador soporte. El iframe ejecuta el mismo motor JS que la página padre, por lo que un usuario de Chrome obtiene V8, un usuario de Firefox obtiene SpiderMonkey, un usuario de Safari obtiene JavaScriptCore. Las características modernas (encadenamiento opcional, top-level await, clases, async/await, sintaxis ES2024) funcionan si tu navegador las soporta. Para pruebas dirigidas a navegadores más antiguos, pega salida transpilada de Babel o swc.
¿Puedo cargar scripts y hojas de estilo externas?
Sí para la mayoría de CDN públicos. <script src="https://cdn.jsdelivr.net/..."> y <link href="https://cdn.tailwindcss.com" rel="stylesheet"> usualmente funcionan porque esos CDN establecen encabezados CORS permisivos. Los recursos que requieren credenciales o están bloqueados por origen fallarán. El panel Network en las DevTools de tu navegador muestra exactamente qué recursos cargaron y cuáles fueron bloqueados.
¿En qué se diferencia esto de CodePen / JSFiddle / StackBlitz?
Esos son servicios completos de hosting de código con funciones de guardar / compartir / fork / colaboración y requieren cuentas. Esta herramienta es un borrador de una sola página: sin cuenta, sin guardado, sin compartir, sin analítica. Pega, previsualiza, itera, cierra la pestaña. Para algo que quieras mantener o compartir, CodePen sigue siendo la mejor opción.
¿Se sube mi código a algún sitio?
No. El HTML / CSS / JS que pegas se envuelve en <iframe srcdoc="..."> en la misma página y se renderiza en un origen único en sandbox en tu navegador. Ninguna llamada de red transporta tu contenido. Los recursos externos que tu HTML referencia (imágenes, scripts, hojas de estilo) son obtenidos por tu navegador de la misma forma que lo serían en cualquier página web, pero el código fuente mismo nunca abandona la página.