Preview HTML en vivo: el editor online en castellano para probar HTML, CSS y JavaScript sin instalar nada

Por qué publicamos este editor (y a quién le ahorra tiempo)

Si trabajas con HTML, CSS o JavaScript habrás tenido más de una vez el siguiente flujo: alguien te pasa un snippet por Slack, Discord o un correo, lo abres, dudas si funciona, abres VS Code, creas un archivo prueba.html, pegas el código, lo abres en el navegador, modificas, recargas, modificas, recargas… diez minutos más tarde sigues sin saber si la idea era buena. El editor Preview HTML en vivo que acabamos de publicar elimina ese paseo: pegas, ves, modificas y descargas, todo en la misma pestaña del navegador, sin instalar nada y sin que el código abandone tu equipo.

No es una alternativa al IDE en proyectos grandes. Es la herramienta que falta entre "abrir DevTools y editar HTML inline" y "montar un proyecto Next/Vite/Astro". Cuando el snippet es pequeño, la duda es rápida y el ciclo iterativo importa, este editor sustituye perfectamente a una pestaña de CodePen o JSFiddle, con dos diferencias clave: no requiere cuenta y no envía nada a un servidor.

A lo largo de este artículo voy a desgranar las funcionalidades que hemos implementado, justificar las decisiones técnicas que hay detrás (sandbox, persistencia local, fuentes monospace), revisar cinco casos de uso reales con los que esta herramienta ahorra tiempo de verdad, y compararlo de tú a tú con CodePen, JSFiddle y JS Bin para que puedas elegir bien según el contexto.

Lo que el editor hace, sin tecnicismos

Tres pestañas: HTML, CSS, JavaScript. Tres editores con resaltado de sintaxis y números de línea. Y un panel de preview a la derecha (en pantallas grandes) o debajo (en móvil) que renderiza el resultado al instante a medida que escribes. El motor del preview es un <iframe> con srcdoc y sandbox="allow-scripts": tu código corre dentro del iframe pero no puede acceder a esta página padre, ni a tus cookies, ni hacer redirecciones top-level, ni cargar formularios en otra ventana. Es la misma técnica que usan los grandes editores online y la garantía de que abrir el editor y pegar un snippet desconocido es seguro.

Hay un menú de plantillas con ocho ejemplos auto-contenidos para empezar (email transaccional, landing, formulario, tabla, CSS Grid, animaciones, botón glassmorphism y modal accesible), un menú de "añadir librería" para insertar Tailwind, Bootstrap, jQuery, Alpine, htmx o Animate.css con un click, un selector de tamaños de pantalla para simular iPhone/iPad/laptop sin DevTools, y un botón de pantalla completa para presentaciones o trabajos largos. Tu código se auto-guarda en localStorage cada vez que escribes, así que si recargas la página vuelve exactamente al mismo estado.

Las funcionalidades importantes — una a una

Sintaxis resaltada con colores y números de línea

El editor usa react-simple-code-editor sobre Prism.js con una paleta inspirada en el tema tomorrow pero ajustada al navy de GarTools. Las etiquetas HTML salen en rojo claro, los atributos en naranja, los strings en verde, las propiedades CSS en azul y los keywords JavaScript en violeta. Cada línea lleva su número a la izquierda alineado a la derecha (el clásico de cualquier IDE) para que cuando alguien te diga "el bug está en la línea 17" sepas exactamente dónde mirar.

Esto puede sonar trivial, pero la diferencia entre un <textarea> plano y un editor con highlighting es enorme tanto para escribir como para leer. Un fallo de sintaxis se ve antes (la coma huérfana se queda sin color), las etiquetas mal cerradas saltan a la vista, y el código en general parece "vivo" en lugar de un bloque de texto opaco.

Persistencia automática en localStorage

Todos los editores online sufren el mismo problema: pulsas F5 sin querer y pierdes 20 minutos de trabajo. En este editor cada cambio se guarda en localStorage con un debounce de 800 ms bajo la clave gartools:preview-html:v1. La próxima vez que entres a la página, los tres editores se rellenan con tu última versión. La pestaña activa (HTML/CSS/JS) y el layout (lado a lado vs apilado) también se recuerdan.

Importante: localStorage es por dispositivo y navegador. Tu trabajo se guarda en este equipo, no se sincroniza entre dispositivos ni viaja a la nube. Eso es coherente con la filosofía de GarTools: privacidad por defecto, sin servidores que necesiten almacenar tu código.

Atajos de teclado de IDE

Cuatro atajos esenciales:

• Ctrl/Cmd + Enter — fuerza la ejecución del preview ahora mismo (útil cuando desactivas el auto-update).
• Ctrl/Cmd + S — descarga el documento empaquetado como un único preview.html listo para abrir directamente con doble click.
• Ctrl/Cmd + / — comenta o descomenta. En HTML envuelve la línea/selección con <!-- -->, en CSS con /* */ y en JS antepone // a la línea o envuelve la selección con /* */ si es de varias líneas. La sintaxis de comentario se ajusta al lenguaje de la pestaña activa.
• Tab — indenta sin sacarte del editor (react-simple-code-editor lo gestiona automáticamente con tabSize: 2).

Galería de ocho plantillas iniciales

Si no sabes por dónde empezar, el menú 📚 Plantillas ofrece ocho puntos de partida que cubren los casos más habituales. Cada plantilla rellena los tres editores con código limpio y comentado:

Plantilla	Caso de uso típico
✉️ Email HTML básico	Newsletter o transaccional con tablas inline al estilo Mailchimp
🚀 Landing page	Hero + features + footer responsivos sin frameworks
📨 Formulario de contacto	Validación HTML5 nativa + JS que muestra feedback
📊 Tabla responsiva	Cabecera sticky, scroll horizontal en móvil y ordenable al click
🟦 CSS Grid playground	grid-template-columns con auto-fit y minmax
✨ Animación CSS	Spinner + hover + typewriter, sin librerías
💎 Botón glassmorphism	Backdrop-filter, gradientes y efecto ripple en JS
🪟 Modal con backdrop	Modal accesible (role, aria) con cierre por Escape

Las plantillas también aparecen como cards visuales en una galería más abajo en la propia página de la herramienta para que sean explorables sin abrir el menú.

Quick-add de librerías por CDN

A veces lo único que necesitas es probar un componente Tailwind o un script jQuery sin escribir el <script> a mano. El menú ➕ Librería inserta la etiqueta correspondiente al inicio del HTML con un click. Las seis librerías incluidas son:

• Tailwind CSS (vía cdn.tailwindcss.com, ideal para prototipos rápidos).
• Bootstrap 5 (CSS + JS bundle desde jsDelivr).
• jQuery 3 (la edición moderna, no la deprecada del proyecto original).
• Alpine.js (el "Vue ligero" para añadir reactividad declarativa).
• htmx (HTML hypermedia con partial swaps, lo nuevo del 2024).
• Animate.css (animaciones declarativas con clases).

Si necesitas otra librería específica, escribe la etiqueta a mano: cualquier CDN absoluta funciona dentro del iframe, ya que el sandbox sólo restringe el acceso al parent y no las peticiones HTTP del propio iframe.

Simulador de tamaños de pantalla

Encima del iframe hay cinco botones que ajustan el ancho del preview para emular dispositivos:

• 📱 iPhone (375 px) — el ancho que la mayoría de teléfonos Android emulan también
• 📱 iPhone Pro (430 px) — pantalla de iPhone 15/16 Pro Max
• 🟦 iPad (768 px) — el breakpoint clásico para tablet vertical
• 💻 Laptop (1024 px) — el ancho mínimo para diseño "desktop"
• 🖥️ Full — ocupa todo el ancho disponible del panel

El iframe se centra automáticamente cuando reduces el ancho, dejando un margen gris a los lados que recuerda al simulador de DevTools. Es la forma más rápida de comprobar si tu media query funciona sin abrir las herramientas de desarrollo del navegador.

Pantalla completa para presentaciones

El botón ⛶ Pantalla completa sobre la barra del preview abre un modal a toda pantalla con el iframe ocupando casi toda la ventana. Útil para enseñarle el resultado a un cliente sentado a tu lado, para presentar en una reunión o, simplemente, para concentrarte en el resultado sin distracciones. Se cierra con la tecla Escape o con el botón ✕ Cerrar de la esquina.

Layout split por defecto en pantallas grandes

En escritorios y portátiles (≥1024 px) la herramienta arranca con layout lado a lado: editor a la izquierda, preview a la derecha. Es el patrón clásico de cualquier editor visual y permite ver el cambio inmediatamente al escribir. Si prefieres tener todo el ancho para el editor (por ejemplo, cuando estás escribiendo HTML largo), puedes cambiar a apilado con el toggle de la esquina superior derecha. En móvil siempre está apilado porque las pantallas estrechas no soportan dos paneles cómodamente.

Cinco casos reales donde nos ahorra tiempo

1. Editar plantillas de email transaccional

Las plantillas de email son el caso de uso donde más he usado preview HTML personalmente. Las plataformas de email (Mailchimp, Brevo, Postmark, SendGrid) trabajan con HTML al estilo años 2000: tablas anidadas, CSS inline en cada celda, sin flexbox ni grid porque Outlook usa el motor de Word para renderizar. Pegar tu plantilla aquí y verla renderizada al instante mientras ajustas paddings, colores y la jerarquía tipográfica acorta el ciclo de iteración a segundos.

Truco: para emular cómo se vería en un cliente de email móvil, selecciona el simulador a iPhone 375 px. La inmensa mayoría de los emails se abren en móvil, y un email diseñado pensando solo en escritorio queda regular en pantallas pequeñas.

2. Aprender HTML, CSS y JavaScript sin abrir VS Code

Si estás siguiendo un curso, un libro o un tutorial en YouTube, el ciclo "ver el ejemplo → reproducirlo → modificarlo" es la forma más eficaz de aprender. Y abrir un editor pesado como VS Code o WebStorm para escribir 30 líneas de código es un overkill que resta motivación. Aquí copias el ejemplo, lo modificas, ves el cambio inmediatamente, y cuando termines puedes descargar tu versión final como archivo .html para guardarla como referencia.

Para cursos de CSS específicamente, recomiendo cargar la plantilla CSS Grid playground y experimentar con grid-template-columns, gap, minmax y auto-fit. Es uno de los temas que más cuesta visualizar leyendo y más rápido se entiende viendo el resultado en tiempo real.

3. Reproducir bugs y respuestas de Stack Overflow

Cuando estás depurando un problema y encuentras una respuesta interesante en Stack Overflow, lo natural es querer probar el snippet antes de integrarlo en tu proyecto real. Antes había dos opciones: copiarlo a tu proyecto y rezar (caro si rompe algo), o crear un archivo prueba.html aparte (lento). Aquí lo pegas, ves si funciona, modificas valores hasta entender qué hace, y luego sí lo integras donde corresponde con conocimiento de causa.

Es especialmente útil para snippets de CSS clip-path, box-shadow complejo, gradientes radiales, animaciones con keyframes y otras propiedades visuales donde la documentación con texto no termina de transmitir el resultado.

4. Demos rápidas a clientes y compañeros

Cuando un diseño está en revisión, mandar un mockup vivo (aunque sea un solo componente) supera a una captura estática en un PDF. El flujo natural sería: maquetas el componente aquí, comprobar que funciona en iPhone, iPad y laptop con el simulador, descargas como preview.html y se lo envías por email o lo subes a un servidor estático tipo Netlify Drop o Vercel.

Otra alternativa más rápida: dejas el editor abierto en pantalla compartida durante una videollamada, modificas en directo según el feedback del cliente, y al terminar la reunión la versión final ya está guardada en localStorage lista para refinar después.

5. Probar componentes Tailwind, Bootstrap o htmx sin instalar nada

¿Quieres ver cómo se ve un determinado utility de Tailwind, una clase de Bootstrap, un componente de DaisyUI o un patrón htmx? Carga la librería desde el menú ➕ Librería, escribe el snippet, ve el resultado. No necesitas montar un proyecto, ni configurar PostCSS, ni instalar dependencias. Para validar una idea en cinco minutos esto es lo más rápido del mercado.

Limitación honesta: las features de Tailwind que requieren purge (clases dinámicas, JIT) no aplican porque el modo CDN incluye Tailwind completo en runtime. Para producción nunca uses CDN; para prototipos rápidos es perfecto.

Comparativa honesta con CodePen, JSFiddle y JS Bin

Aspecto	GarTools Preview	CodePen	JSFiddle	JS Bin
Requiere cuenta	❌ no	✅ sí (para guardar)	✅ sí (para guardar)	✅ sí (para guardar)
Funciona offline tras carga	✅ sí	❌ no	❌ no	❌ no
Tu código va a un servidor	❌ no	✅ sí	✅ sí	✅ sí
Sandbox del preview	✅ allow-scripts	✅ múltiple	✅ múltiple	✅ allow-scripts
Plantillas iniciales	✅ 8	✅ muchas	✅ algunas	❌ no
CDN library quick-add	✅ 6	✅ amplio	✅ amplio	❌ no
Simulador responsive	✅ 5 tamaños	✅ "Live View"	❌ no	❌ no
Compartir vía URL	❌ no	✅ sí	✅ sí	✅ sí
Galería pública	❌ no	✅ sí	✅ sí	❌ no
Colaboración en tiempo real	❌ no	✅ Pro	❌ no	❌ no
Coste	Gratis sin límite	Gratis con límites	Gratis con límites	Gratis
Idioma de la interfaz	🇪🇸 castellano	🇬🇧 inglés	🇬🇧 inglés	🇬🇧 inglés

Resumen: si quieres guardar pens públicamente, compartir por URL o colaborar, ve a CodePen. Si quieres probar algo rápido en castellano sin registro y sin que tu código viaje a un servidor, este editor cubre el 80% de los casos sin coste cognitivo. Para nosotros las dos herramientas conviven: usamos GarTools para snippets internos, CodePen cuando queremos compartir un demo público con URL pretty.

Privacidad: por qué nada de lo que escribas sale del navegador

Es la pregunta que se hace cualquiera que pega código sensible (un fragment de un componente propietario, una plantilla de email con datos reales, una clave API de prueba que se le coló): ¿esto se está enviando a algún sitio?. La respuesta es no, y se puede comprobar trivialmente.

Abre las DevTools (F12), ve a la pestaña Network, y escribe en cualquiera de los tres editores. Verás que ninguna petición HTTP se dispara como consecuencia de tus cambios. La excepción son los recursos externos que tú mismo importes (las CDNs como Tailwind o jQuery): esas sí harán sus peticiones desde el iframe, pero eso es comportamiento normal del HTML que tú escribiste. La herramienta en sí no añade ninguna telemetría sobre el contenido del editor.

El localStorage queda guardado en tu navegador. Si limpias la caché, lo pierdes. Si entras desde otro dispositivo, no aparece. No hay sincronización en la nube ni copia de seguridad. Es deliberado: privacidad por diseño.

Trucos avanzados que no son obvios

Cargar Google Fonts: añade dentro del HTML <link rel="preconnect" href="https://fonts.googleapis.com"> y <link href="https://fonts.googleapis.com/css2?family=Inter:wght@400;600;800&display=swap" rel="stylesheet">. Después en el CSS escribe body { font-family: 'Inter', sans-serif; }. Funciona idéntico a producción.

Inyectar SVG inline: pegar el SVG completo dentro del HTML funciona perfectamente. Para SVGs grandes, usa los atributos width y height para limitar el tamaño y evita que ocupe toda la página.

Trabajar con fetch y APIs externas: el iframe puede hacer peticiones fetch siempre que la API destino tenga CORS abierto (cabecera Access-Control-Allow-Origin: *). APIs públicas como JSONPlaceholder, OpenWeather (con clave) o REST Countries funcionan sin problemas. APIs privadas que requieran cookies o autenticación con sesión normalmente no, porque el origen del iframe es about:srcdoc y los servidores no lo reconocen.

Hacer que el preview reaccione a media queries del iframe (no del navegador): el iframe sirve un documento independiente, así que las media queries dentro del CSS del iframe miden el ancho del propio iframe. Esto significa que el simulador de tamaños activa correctamente media queries (@media (max-width: 600px)) según el ancho seleccionado, no según el ancho real de tu pantalla. Es la diferencia entre "ver el preview pequeño" y "ver el diseño responsive funcionando".

Usar localStorage dentro del preview: el iframe sandbox tiene su propio localStorage aislado, así que puedes probar componentes que usan persistencia local sin contaminar la herramienta. Recuerda que se borra al recargar el iframe.

Probar service workers o WebSockets: ambos requieren un origen real (no about:srcdoc), así que no funcionan dentro de este editor. Para esos casos necesitas un dev server real (Vite, Next, Parcel).

Cuándo NO usar este editor

Para que la honestidad funcione en los dos sentidos:

• Proyectos con varios archivos: un snippet sí, una mini-app con /components/Button.jsx no. Necesitas un bundler.
• Imports de módulos ES con resolución de paquetes: import React from "react" no funciona; sí funciona si añades los <script type="module"> con URLs absolutas a esm.sh, jsdelivr o skypack.
• Hot Module Replacement durante desarrollo de un proyecto serio.
• Build de producción: este editor es para iterar y probar, no para servir tráfico real.
• Service Workers, WebSockets, fetch a APIs con cookies de sesión: requieren un origen real.
• TypeScript, JSX, SCSS, Less compilados: tendrías que escribir el resultado plano (tsc, sass) a mano antes de pegarlo.

Para todo lo anterior, levanta un proyecto Vite o Next y deja este editor para snippets pequeños.

Conclusión: el block de notas con render

El editor de Preview HTML en vivo no pretende reemplazar a tu IDE ni a CodePen. Pretende ser el block de notas con render que falta entre "no tengo proyecto abierto" y "necesito montar un proyecto para esto". Cinco minutos para probar una idea, cinco segundos para descargarla como un .html standalone, cero registros, cero subidas a la nube.

Si has llegado hasta aquí, lo más útil que puedes hacer ahora es abrir el editor, pulsar en 📚 Plantillas → Animación CSS, y trastear cinco minutos. La forma más rápida de entender qué hace una herramienta es usarla, y este artículo no es sustituto de eso. Si encuentras algo que falta o un detalle que mejorar, los comentarios en el GitHub público de GarTools son el sitio para reportarlo: cada release de la última semana ha incorporado feedback real de gente que la ha usado.

Y si te ha gustado, los siguientes en la cola del Tier 1 son un JWT decoder, un conversor JSON ↔ YAML y un generador UUID v4/v7. Son el tipo de utilidades técnicas que los desarrolladores buscan a diario y que no existen en castellano con calidad decente. Si crees que falta alguna otra que te sería útil, dímelo y la sumo a la lista.