Lanzamiento Lifetime— 23 de 100 cupos a $49 · $99Reserva tu cupo
Hosting HTML

Aloja un archivo HTMLcomo enlace en vivo

Arrastra un archivo HTML aquí y obtén un enlace limpio que lo renderiza en vivo en el navegador — sin servidor, sin DNS, sin paso de compilación.

Suelta your file aquí

Suelta varios a la vez y se convierten en un enlace de álbum

Archivos de hasta 100 MB gratis

Gratis: 20 enlaces, hasta 100 MB · Pro: enlaces ilimitados, subidas más grandes

Aloja un archivo HTML en cuatro pasos

  1. 1

    Conviértelo en un archivo autocontenido

    Incluye tu CSS en una etiqueta <style> y tu JS en una etiqueta <script>, y referencia las imágenes con URLs completas https:// o como data URIs en base64. Si tu CSS/JS/imágenes están en archivos separados ahora mismo, este es el único paso de preparación que importa — todo lo que la página necesita debe estar dentro del único .html que subas.

  2. 2

    Sube el archivo .html

    Arrástralo sobre la tarjeta e inicia sesión con Google — un toque, sin formulario. Una cuenta gratuita te da 20 páginas alojadas, de hasta 100 MB cada una. El archivo se valida por sus bytes reales, no por su nombre, por lo que solo se acepta HTML genuino.

  3. 3

    Abre el enlace en vivo para comprobar el renderizado

    Tu página se sirve en un enlace limpio y compartible, y se muestra en vivo en una vista de navegador en sandbox. Ábrela tú primero — porque los scripts se ejecutan de forma aislada, una página que intente acceder a la ventana padre o a una cookie del mismo origen se comportará de manera diferente que en localhost. Corrige y vuelve a subir si es necesario.

  4. 4

    Comparte el enlace (o su código QR)

    Envía la URL, o descarga el código QR generado automáticamente para incluirlo en una diapositiva, un impreso o un cartel. Cada apertura incrementa un contador de visitas para que puedas ver que la página realmente está siendo vista.

Un sitio de una página con cero infraestructura

El caso clásico: has programado a mano un index.html — una página de «próximamente», un RSVP para un evento, un link-in-bio, una página de detalles de boda — y cada guía de alojamiento quiere que compres un dominio, apuntes los nameservers y esperes la propagación. Aquí la página está en vivo en el segundo en que termina la subida, en un enlace que puedes compartir por mensaje de texto. Como se renderiza en vivo en lugar de mostrar el código, los visitantes ven la página real con su maquetación, fuentes y estados hover intactos. El límite real: es genuinamente un solo archivo. Si tu sitio es index.html más una carpeta /css y una carpeta /images, o bien integras todo en ese único archivo o esta no es la herramienta adecuada — un conjunto de recursos no se ensambla solo.

Compartir un informe HTML exportado

Muchas herramientas exportan un .html autocontenido: un informe de cobertura de pytest o Jest, una ejecución de Playwright, un resumen de Allure o pandas-profiling, una auditoría de Lighthouse, un notebook de Jupyter guardado como HTML. Estos ya están diseñados para ser un solo archivo con todo integrado, lo que los convierte en una opción casi perfecta. En lugar de comprimir el informe y enviarlo por correo — donde el destinatario tiene que descargarlo, descomprimirlo y encontrar el archivo de entrada — envías un solo enlace que abre el informe interactivo en su navegador. El contador de visitas te indica que el cliente o compañero realmente lo abrió, y el enlace sigue funcionando para la próxima persona que lo necesite. Los gráficos interactivos y las tablas colapsables siguen funcionando siempre que su JS haya sido integrado en la exportación.

Vista previa de un correo HTML o newsletter codificado

El correo HTML es un formato doloroso por sí solo — tablas anidadas, estilos inline, sin hojas de estilo externas — y antes de lanzar una campaña quieres que un responsable vea el resultado renderizado, no el código fuente. Pega tu salida de Mailchimp, Klaviyo o MJML compilado en un archivo .html, alójalo y envía el enlace para su aprobación. Dos advertencias honestas que vale la pena mencionar desde el principio: un renderizado en navegador no es un renderizado real en bandeja de entrada (Gmail y Outlook modifican el HTML a su manera, así que úsalo para revisar maquetación y texto, no para el QA final de entregabilidad), y cualquier píxel de seguimiento o enlace de rastreo de clics incluido en la exportación seguirá apuntando a tu ESP. Elimínalos de la copia de revisión si no quieres que tus propias aperturas de prueba se contabilicen.

Un fragmento de landing o demo de código renderizado

Cuando estás haciendo prototipos, a menudo tienes un solo archivo que es todo el proyecto: un hero de landing con Tailwind vía CDN, una animación CSS de la que estás orgulloso, un sketch con canvas, una demo pequeña de D3 o Three.js, un componente que construiste para mostrar a un cliente. Un enlace en vivo supera a un CodePen o una captura de pantalla cuando quieres que parezca una página real en una URL real — sin el entorno del editor alrededor, se abre a pantalla completa en un teléfono. Mientras tus bibliotecas carguen desde un CDN por https y tu código esté integrado, funciona. Esta es la forma más rápida de convertir «aquí hay una idea aproximada» en «abre esto en tu teléfono» sin un pipeline de despliegue.

Por qué se renderiza en un sandbox (y qué significa eso)

Tu HTML se sirve dentro de un frame en sandbox sin acceso al mismo origen. Esto protege tanto a ti como a cada visitante: el marcado no confiable no puede leer cookies, no puede acceder a la página padre y no puede actuar como si formara parte del host. Para el 95% de las páginas — maquetación, estilos, animaciones, bibliotecas CDN, scripts autocontenidos — nunca lo notarás. Donde sí lo notarás: código que asume que controla la ventana de nivel superior, que necesita cookies de primera parte o localStorage, o que habla con una API que solo permite un origen específico (CORS). Esas son preocupaciones de apps personalizadas, y para ellas un host real es la opción correcta. En Pro puedes poner una página alojada en tu propio dominio en la barra de direcciones con SSL automático, pero la página sigue renderizándose en sandbox, por lo que se aplican los mismos límites de scripts. Para alojar una página con el fin de que sea vista, el sandbox es una característica, no una limitación.

Para quién es esto — y quién debería buscar otra opción

Ideal para: desarrolladores, diseñadores, estudiantes, marketers y constructores sin código que tienen un único .html terminado y necesitan una URL ahora — una demo para un cliente, un informe para un manager, un fragmento para un compañero, una página única para un evento. No es la opción adecuada para: un sitio de varias páginas con enlaces internos entre archivos .html, una app que necesita un backend o variables de entorno, cualquier cosa que requiera tu propio dominio en la barra de URL, o un paso de compilación que genere una carpeta /dist con recursos separados. Para eso, usa un host real. Si tu único obstáculo era «no quiero configurar alojamiento para un solo archivo», esto elimina exactamente ese obstáculo y nada más.

Preguntas frecuentes

¿Sigues con dudas? Escríbenos directamente — responde una persona real.

Sí. Todo lo que la página necesita debe estar dentro del único archivo o cargarse desde una URL https:// — integra tu CSS y JS, y referencia las imágenes como URLs completas o data URIs en base64. Los archivos .css/.js separados o una carpeta de imágenes no se vincularán.

Tu enlace está a 10 segundos

Inicia sesión gratis con Google — un toque, sin formularios — y comparte un enlace limpio y medible.

Empieza gratis

Explorar más

Enlace de portafolio Alternativa a Tiiny Host Compartir archivos solo lectura Compartir archivos en línea