HTML-Vorschau

Du hast ein HTML-Schnipsel vor dir und willst wissen, wie es aussieht. Bevor es irgendwo landet. Sonst heißt das: Datei anlegen, Browser öffnen, Tab wechseln, wieder zurück. Hier fällt der Umweg weg. Links tippst du dein Markup, rechts siehst du sofort das Ergebnis. Ganz ohne eigenes Projekt und ohne Build-Schritt.

Gedacht ist das Tool für den schnellen Blick, nicht für ein komplettes Layout. Ein Snippet aus einer E-Mail, eine Antwort von ChatGPT, ein altes Codefragment aus einem Ordner. Bevor du so etwas irgendwo einfügst, willst du wissen, was es tatsächlich anzeigt.

So funktioniert es

Du tippst im linken Feld. Die Vorschau rechts aktualisiert sich bei jedem Tastenanschlag. Kein Button zum Auslösen, keine Wartezeit, kein Server dazwischen. Standardmäßig steht dort ein kurzes Beispiel mit einer Überschrift und einem Absatz. Du markierst es und ersetzt es durch dein eigenes Markup.

Die Vorschau läuft in einem iframe mit dem Attribut sandbox="", also ohne einen einzigen Freigabe-Wert. Das ist die strengste Stufe, die der iframe-Standard kennt. sandbox funktioniert wie eine Positivliste: Nur was explizit erlaubt ist, darf laufen.

Ohne allow-scripts führt der Frame kein einziges <script>-Tag aus, es steht nur wirkungslos im Markup. Ohne allow-forms sendet kein Formular ab, ohne allow-popups öffnet sich kein neues Fenster, und ohne allow-same-origin kann der Frame nicht auf diese Seite zugreifen, selbst wenn im eingefügten Code jemand das versuchen würde.

Und ein letzter Punkt, der beim Testen von fremdem Code beruhigt: Nichts von dem, was du einfügst, verlässt deinen Browser. Es gibt keinen Upload und keinen Request an irgendeinen Server. Der Text bleibt lokal im Tab, auch wenn er aussieht wie ein komplettes Formular oder ein eingebettetes Widget.

Wann du es brauchst

Am häufigsten für Markup, dem du noch nicht traust. Ein Kunde schickt ein Embed-Snippet. Ein Kollege ein HTML-Fragment aus einem alten CMS. Ein Chatbot liefert dir Code und behauptet, er würde eine bestimmte Struktur ergeben. Bevor das irgendwo in eine echte Seite wandert, prüfst du es hier. Ein enthaltenes Skript läuft dabei nie tatsächlich.

Genauso praktisch beim Lernen. Wer HTML gerade erst versteht, sieht direkt, was ein <ul> gegenüber einem <ol> macht. Oder wie sich verschachtelte <div>s auf die Struktur auswirken, ohne dafür einen Editor und einen lokalen Server aufzusetzen. Und für dich selbst, wenn du dir mitten in einer anderen Aufgabe kurz ein Tag-Verhalten in Erinnerung rufen willst: Snippet rein, Ergebnis lesen, weiterarbeiten.

Was ein Sandbox-iframe blockiert, und was nicht

Der sandbox-Wert ist ein Satz einzelner Tokens. Jedes schaltet genau eine Fähigkeit frei:

• allow-scripts für JavaScript
• allow-forms für Formularübermittlung
• allow-popups für neue Fenster oder Tabs
• allow-same-origin dafür, dass der Frame seinen eigenen Ursprung behält, statt als leere null-Origin zu laufen
• allow-top-navigation dafür, dass der Inhalt die übergeordnete Seite umleiten darf

Dieses Tool setzt keines davon. Es bleibt reines Markup und reines CSS übrig. Genau das willst du für eine Vorschau, bei der du nicht weißt, was im eingefügten Code eigentlich steckt.

Was trotzdem funktioniert: alles, was der Browser ohne Skript darstellt. Überschriften, Absätze, Listen, Tabellen und Formulare als reine Struktur. Eingebettetes CSS über <style>-Tags, sogar CSS-Animationen, weil die kein JavaScript brauchen. Nur Verhalten, das aktiv Code ausführt, bleibt aus.

Zwei Fallstricke beim Testen von Fragmenten

Ein Snippet ohne eigenes <style> bleibt unformatiert. Der iframe bekommt nur das, was du einfügst. Er erbt keine Stile von dieser Seite und auch nicht von irgendeiner anderen Quelle. Willst du sehen, wie ein Element mit seinem eigentlichen CSS aussieht, gehört das CSS mit ins selbe Fenster. Entweder inline im style-Attribut oder in einem eigenen <style>-Block.

Relative Pfade gehen ebenfalls ins Leere. Ein <img src="logo.png"> verweist im Sandbox-Frame auf nichts, weil kein allow-same-origin gesetzt ist. Der Frame hat also keinen festen Ursprung, von dem aus ein relativer Pfad aufgelöst werden könnte. Für Bilder brauchst du eine vollständige URL oder ein Data-URI mit dem Bild direkt eingebettet.

Was es nicht kann

Es ist eine Vorschau, kein Editor mit Zusatzfunktionen. Es bereinigt keine eingefügten Inline-Styles, minifiziert nichts und formatiert verschachtelten Code nicht automatisch lesbar. Willst du Text aus Word oder Google Docs sauber weiterverarbeiten, ist der Markdown-Editor der bessere Ausgangspunkt. Er erzeugt echten Rich Text statt nur eine Vorschau zu zeigen.

Es gibt außerdem keinen Copy-Button, keinen Reset und keinen Speicherplatz. Schließt du den Tab oder lädst die Seite neu, ist der Text weg. Kopier dir dein Ergebnis also, bevor du wegklickst. Und weil kein Skript läuft, siehst du auch nicht, wie sich dynamisch erzeugtes Markup verhält. Für eine Komponente, die erst durch JavaScript ihre endgültige Struktur bekommt, brauchst du eine echte Entwicklungsumgebung, keine Sandbox-Vorschau.

Wenn du öfter Code baust statt nur zu prüfen, lohnt sich ein Blick in zwölf weitere kostenlose Tools. Sie sind aus genau demselben Grund entstanden: für Aufgaben, bei denen ein vollständiges Projekt Overkill wäre. Wer wissen will, wie ein Coding-Agent ganze WordPress-Themes baut, findet dort das andere Ende der Skala, samt validem Gutenberg-Markup am Ende.