Primero, una aclaración
Si llegaste aquí buscando la sintaxis HTML <a href="...">, esa es una pregunta diferente. Esta guía es para el caso en que tienes un archivo HTML terminado (un dashboard, un informe de una página, una mini-app generada por LLM, una maqueta de landing page) en tu ordenador, y necesitas una URL que otra persona pueda abrir en un navegador. El problema es el hospedaje, no el HTML.
Por qué es más difícil de lo que debería
El hospedaje HTML es un problema resuelto a gran escala (GitHub Pages, Vercel, S3 más CloudFront, y cientos más), pero el caso "tengo un archivo y quiero un enlace" históricamente ha sido incómodo. El email bloquea los adjuntos .html. Los drives los tratan como descargas. Las plataformas para desarrolladores esperan un repositorio Git. Ninguna fue diseñada para el flujo puntual "enviar esto a mi cliente hoy".
Opción 1: Enviar el .html como adjunto (no lo hagas)
Gmail y Outlook bloquean los adjuntos .html por defecto porque los atacantes los usan para entregar páginas de phishing. Cuando el adjunto llega de todas formas, el destinatario ve un aviso de descarga, no una página renderizada.
Úsalo cuando: el destinatario es un desarrollador que abrirá el archivo intencionalmente en un navegador, y el HTML es pequeño y autocontenido.
Opción 2: Subir a un drive (Google Drive, Dropbox, OneDrive)
El reflejo es soltar el archivo en Drive y copiar el enlace. El problema: los drives sirven los archivos .html como descargas, no como páginas renderizadas. Google Drive solía soportar "vista hospedada" para HTML estático; esa función se ha ido eliminando progresivamente y ya no es fiable para compartir con destinatarios sin cuenta de Google.
Úsalo cuando: quieres que el destinatario descargue el archivo como recurso, no que lo vea como página.
Opción 3: GitHub Pages, Vercel, Netlify, Cloudflare Pages
Estos son servicios de hospedaje estático reales: gratuitos, duraderos, rápidos, con soporte de dominio personalizado y entrega CDN correcta. Si ya usas alguno, esta es la respuesta más robusta.
El coste es la configuración. Necesitas un repositorio Git, un proyecto en la plataforma, a veces configuración de build incluso para un solo archivo estático, y un flujo para subir actualizaciones. El más rápido de todos desde cero (sin cuenta aún) sigue siendo un trabajo de quince minutos.
Úsalo cuando: el archivo es parte de un proyecto, quieres un dominio personalizado y el coste de configuración es una inversión única.
Opción 4: Servicios de arrastrar-y-compartir (LiveSend y similares)
Existe una pequeña categoría de servicios específicamente para el flujo "un archivo, un enlace, sin configuración". La interacción es: arrastra el .html (o pega el código fuente HTML) en un dashboard, obtén una URL pública permanente. Sin repositorio, sin build, sin configuración.
LiveSend es una de esas opciones. Más allá del hospedaje básico, registra cada visita (marca de tiempo, email opcional del visitante, país aproximado, tiempo pasado), te permite añadir contraseña, fijar una fecha de expiración, desactivar el enlace y editar el HTML inline sin cambiar la URL. Las actualizaciones crean versiones a las que puedes volver. Límites honestos: límite de 3 MB (6 MB Pro) por archivo, pequeña marca de agua en el plan gratis (eliminable en Pro), sin soporte de dominio personalizado aún.
Úsalo cuando: quieres un enlace en menos de un minuto, no tienes ni quieres un flujo Git, y el archivo es puntual para un destinatario que solo necesita ver la página.
La respuesta más corta
Si ya despliegas en Vercel o tienes un sitio en GitHub Pages, sube el archivo ahí. Si no, pega el HTML en un servicio de arrastrar-y-compartir y envía la URL. No envíes el adjunto .html por email, y no dependas de un drive: ambos producen un aviso de descarga o fallan silenciosamente.