Hoste eine HTML-Datei als Live-Link

Der Klassiker: Du hast von Hand eine index.html geschrieben, eine Coming-soon-Seite, eine Event-RSVP, ein Link-in-Bio, eine Hochzeits-Infoseite, und jede Hosting-Anleitung will, dass du eine Domain kaufst, Nameserver setzt und auf die Propagierung wartest. Hier ist die Seite live, sobald der Upload fertig ist, unter einem Link, den du per SMS teilen kannst. Weil sie live gerendert wird statt nur den Code zu zeigen, sehen Besucher die echte Seite mit Layout, Schriften und Hover-Zuständen intakt. Die ehrliche Grenze: Es ist wirklich nur eine Datei. Wenn deine Website aus index.html plus einem /css-Ordner und einem /images-Ordner besteht, binde entweder alles in diese eine Datei ein, oder das ist nicht das richtige Werkzeug, ein Haufen loser Dateien verkabelt sich nicht von selbst.

Viele Tools exportieren ein in sich geschlossenes .html: ein pytest- oder Jest-Coverage-Report, ein Playwright-Lauf, eine Allure- oder pandas-profiling-Zusammenfassung, ein Lighthouse-Audit, ein als HTML gespeichertes Jupyter-Notebook. Die sind schon so gebaut, dass alles in einer Datei inline steckt, was sie fast perfekt passend macht. Statt den Report zu zippen und per E-Mail zu schicken, wo der Empfänger herunterladen, entpacken und die Einstiegsdatei finden muss, schickst du einen einzigen Link, der den interaktiven Report direkt im Browser öffnet. Der Aufruf-Zähler zeigt dir, dass der Kunde oder Kollege ihn wirklich geöffnet hat, und der Link funktioniert weiter für die nächste Person, die ihn braucht. Interaktive Diagramme und einklappbare Tabellen funktionieren weiter, solange ihr JS in den Export eingebettet wurde.

HTML-E-Mails sind ein eigenes, mühsames Format, verschachtelte Tabellen, Inline-Styles, keine externen Stylesheets, und bevor du eine Kampagne rausschickst, willst du, dass ein Stakeholder das gerenderte Ergebnis sieht, nicht den Quellcode. Füge deine Mailchimp-, Klaviyo- oder MJML-kompilierte Ausgabe in eine .html-Datei ein, hoste sie und schick den Link zur Freigabe. Zwei ehrliche Vorbehalte vorab: Ein Browser-Rendering ist kein echtes Postfach-Rendering (Gmail und Outlook schreiben Dinge auf ihre eigene Art um, nutze das also für Layout-/Text-Review, nicht als finales QA), und in den Export eingebackene Tracking-Pixel oder Klick-Tracking-Links zeigen weiterhin auf deinen ESP. Entferne die aus der Review-Kopie, wenn du deine eigenen Test-Opens nicht mitzählen willst.

Beim Prototyping hast du oft eine einzige Datei, die das ganze Projekt ist: ein Tailwind-per-CDN-Landing-Hero, eine CSS-Animation, auf die du stolz bist, eine Canvas-Skizze, eine kleine D3- oder Three.js-Demo, eine Komponente, die du für einen Kunden gebaut hast. Ein Live-Link schlägt CodePen oder einen Screenshot, wenn es wie eine echte Seite auf einer echten URL aussehen soll, ohne Editor-Rahmen drumherum, öffnet sich auf dem Handy im Vollbild. Solange deine Bibliotheken über https von einem CDN laden und dein Code inline ist, läuft es. Das ist der schnellste Weg, aus „hier eine grobe Idee“ ein „öffne das auf deinem Handy“ zu machen, ganz ohne Deploy-Pipeline.

Dein HTML wird in einem Sandbox-Frame ohne Same-Origin-Zugriff ausgeliefert. Das schützt dich und jeden Besucher: nicht vertrauenswürdiges Markup kann keine Cookies lesen, nicht auf die übergeordnete Seite zugreifen und nicht so tun, als wäre es Teil des Hosts. Bei 95 % der Seiten, Layout, Styling, Animationen, CDN-Bibliotheken, in sich geschlossene Skripte, merkst du das nie. Wo du es merken wirst: Code, der davon ausgeht, dass er das oberste Fenster besitzt, der First-Party-Cookies oder localStorage braucht, oder der mit einer API spricht, die nur einen bestimmten Origin erlaubt (CORS). Das sind Themen für individuelle Web-Apps, und dafür ist ein echter Host die richtige Wahl. In jedem Tarif kannst du eine gehostete Seite mit automatischem SSL unter deiner eigenen Domain in der Adressleiste anzeigen lassen, aber die Seite rendert weiterhin in der Sandbox, also gelten dieselben Skript-Grenzen. Für eine Seite, die einfach angeschaut werden soll, ist die Sandbox ein Feature, keine Einschränkung.

Perfekt für: Entwickler, Designerinnen, Studierende, Marketer und No-Code-Bauer, die eine fertige einzelne .html haben und jetzt eine URL brauchen, eine Demo für einen Kunden, ein Report für eine Führungskraft, ein Snippet für einen Kollegen, eine Ein-Seiten-Seite für ein Event. Nicht die richtige Wahl für: eine Mehrseiten-Website mit internen Links zwischen .html-Dateien, eine App, die ein Backend oder Umgebungsvariablen braucht, alles, was deine eigene Domain in der URL-Leiste erfordert, oder ein Build-Schritt, der einen /dist-Ordner mit separaten Assets ausgibt. Nutze dafür einen echten Host. Wenn dein einziges Hindernis war „ich will für eine einzige Datei kein Hosting einrichten“, beseitigt das genau dieses Hindernis und nicht mehr.