HTML-Vorschau / Code-Spielwiese

Schreiben Sie HTML, CSS und JavaScript in den Editoren unten und sehen Sie das Ergebnis sofort im Vorschau-Bereich.

Vorschau

Funktionsweise

  1. HTML einfügen oder tippen: Geben Sie Ihren HTML-Code ein (vollständige Dokumente, Fragmente, Vorlagen oder E-Mail-HTML) in den Editor.
  2. Live-Rendering sehen: Das Vorschau-Panel zeigt genau, wie der Browser Ihr HTML in Echtzeit rendert.
  3. Schnell iterieren: Bearbeiten und Vorschau in einer engen Schleife, ohne Browser-Tabs zu wechseln oder Dateien zu speichern.

Warum die HTML-Vorschau nutzen?

Beim Schreiben von HTML für Vorlagen, E-Mails, Komponenten oder statische Seiten brauchen Sie ständiges Feedback dazu, wie das Markup gerendert wird. Dateien im Browser zu öffnen und manuell zu aktualisieren, unterbricht Ihren Workflow. Dieses HTML-Vorschau-Tool rendert Ihr HTML sofort beim Tippen und gibt Ihnen eine Live-Visualisierung im selben Fenster, ideal für schnelles Iterieren bei Vorlagen, das Debuggen von Layout-Problemen und das Testen von HTML-E-Mails vor dem Versand.

Funktionen

Häufig gestellte Fragen

Kann ich HTML-E-Mails in der Vorschau anzeigen?

Ja. Fügen Sie Ihr E-Mail-HTML einschließlich Inline-Styles und tabellenbasierter Layouts ein. Die Vorschau rendert genau so, wie es ein E-Mail-Client tun würde. Beachten Sie, dass externe Schriften und einige CSS-Funktionen sich in tatsächlichen E-Mail-Clients anders verhalten können.

Funktionieren externes CSS und JavaScript?

Externe Stylesheets, die über <link>-Tags geladen werden, laden möglicherweise nicht aufgrund von CORS-Einschränkungen in der Sandbox-Vorschau. Die JavaScript-Ausführung ist durch die Sandbox eingeschränkt. Für die besten Ergebnisse verwenden Sie Inline-CSS. Externe Ressourcen von CDNs, die Cross-Origin-Zugriff erlauben, laden normal.

Kann ich damit responsive Designs testen?

Ja. Ziehen Sie die Breite des Vorschaupanels, um verschiedene Bildschirmgrößen zu simulieren, oder nutzen Sie die Viewport-Presets (mobil, Tablet, Desktop), um Ihre responsiven Breakpoints zu testen.

Wie die Live-Vorschau funktioniert: iframe srcdoc

Das <iframe>-Element wurde in HTML 4.0 (Dezember 1997) eingeführt, um ein Dokument in einem anderen einzubetten. Zwei Jahrzehnte lang war der einzige Weg, ein iframe zu befüllen, über das src-Attribut, das auf eine URL zeigte. Das srcdoc-Attribut, mit dem Sie das HTML des iframes inline als Zeichenkette übergeben können, wurde in HTML5 (W3C Rec, Oktober 2014) hinzugefügt und wird heute von jedem modernen Browser unterstützt. srcdoc ist das, was ein browserbasiertes HTML-Vorschau-Tool ohne Server-Upload möglich macht: Sie schreiben HTML, das Tool wickelt es in <iframe srcdoc="..."> ein, der Browser rendert es in einem isolierten Kontext, und nichts überquert das Netzwerk.

Das sandbox-Attribut und die Same-Origin-Falle

<iframe sandbox> wurde in HTML5 eingeführt, um eine pro-iframe-Sicherheitsrichtlinie anzuwenden. Mit keinem Wert gilt die restriktivste Sandbox: Same-Origin eingeschränkt (als eindeutiger Ursprung behandelt), Skripte deaktiviert, Formulare deaktiviert, Top-Level-Navigation deaktiviert, Plugins deaktiviert, Pointer-Lock deaktiviert, Popups deaktiviert, Auto-Play von Medien deaktiviert. Sie aktivieren wieder durch Hinzufügen von Token: sandbox="allow-scripts", allow-forms, allow-popups, allow-top-navigation usw. Jeder Token öffnet eine bestimmte Fähigkeit.

Die niemals zu verwendende Kombination ist sandbox="allow-scripts allow-same-origin" gleichzeitig: Das erlaubt JavaScript, document.domain aufzurufen und zum Elternfenster zurückzulaufen, was die Sandbox vollständig zunichtemacht. Browser warnen in DevTools davor, wenn Sie beide setzen. Dieses Vorschau-Tool setzt allow-scripts und explizit NICHT allow-same-origin, sodass Benutzer-JS läuft, aber den DOM, die Cookies, localStorage, IndexedDB oder Service-Worker-Caches der Elternseite weder lesen noch beschreiben kann.

Content Security Policy, die zweite Verteidigungslinie

Eine getrennte aber verwandte Verteidigung ist Content-Security-Policy, ein HTTP-Antwort-Header, der in W3C CSP Level 1 (Candidate Recommendation, November 2012) eingeführt wurde. CSP Level 3 ist der aktuelle Standard. Die Schlüsseldirektive für Vorschau-Tools: frame-src (welche iframes geladen werden können) und script-src (welche Inline-/externe Skripte laufen können). Selbst wenn eine bösartige Payload aus der Sandbox entkäme, würde der CSP der Host-Seite immer noch gelten und die meisten Exfiltrationspfade verbieten. Verteidigung in der Tiefe: Die Sandbox isoliert den Code des iframes, und der CSP des Hosts begrenzt, was die Host-Seite tun kann, wenn das iframe sie irgendwie beeinflusst hat.

E-Mail-Client-HTML ist eine eigene Welt

Eine Vorschau, die modernes Browser-HTML rendert, rendert nicht E-Mail-HTML. Die wichtigsten E-Mail-Clients verwenden sehr unterschiedliche Engines: Gmail web verwendet einen WebKit-basierten Renderer mit Class-Stripping und begrenzter <style>-Tag-Unterstützung (2016 hinzugefügt). Apple Mail / iOS Mail verwenden WebKit, der permissivste Renderer. Outlook desktop (2007 bis 2019) rendert HTML-E-Mails über die Microsoft-Word-Rendering-Engine: keine <style>-Block-Unterstützung, kein flex/grid, keine positionierten Elemente, keine Animationen; Hintergrundbilder benötigen VML-bedingte Kommentare. Diese Outlook-Eigenheit ist das größte Problem in der E-Mail-Entwicklung. Outlook 365 web ist modernes WebKit. Das «neue Outlook», das 2023-2024 ausgerollt wird, verwendet Edge WebView2. Für echte E-Mail-Client-Vorschauen verwenden Sie einen kostenpflichtigen Service wie Litmus oder Email on Acid.

Zu testende responsive Breakpoints

Die CSS-Media-Query-Breakpoint-Konventionen gehen auf Ethan Marcottes Artikel «Responsive Web Design» vom Mai 2010 in A List Apart zurück. Die zwei dominanten Frameworks haben unterschiedliche Schnitte gewählt:

HTMLs Standards-Stammbaum

Schnellreferenz für die Standards, gegen die Ihre Vorschau rendert: HTML 2.0 (RFC 1866, November 1995), die erste offizielle Spezifikation von Tim Berners-Lee, etablierte das grundlegende Tag-Set. HTML 4.01 (W3C Rec, Dezember 1999) fügte <script>, <style>, <table>, Frames hinzu. XHTML 1.0 (W3C Rec, Januar 2000) versuchte eine strikte XML-Serialisierung, weitgehend bis 2010 aufgegeben. HTML5 (W3C Rec, Oktober 2014) fügte semantische Elemente (<article>, <section>, <nav>), Canvas, video/audio, Web Storage hinzu. Im Mai 2019 übernahm WHATWG die Verwaltung von W3C, und HTML wird nun als Living Standard unter html.spec.whatwg.org gepflegt, kontinuierlich aktualisiert.

Häufige Anwendungsfälle

Häufige Fehler

  1. Versuch, den Inhalt des iframes vom Elternteil zu lesen. Mit gesetztem sandbox blockieren Cross-Origin-Beschränkungen dies. Das iframe kann postMessage hinaussenden, aber der Elternteil kann nicht hineingreifen.
  2. Einfügen von CSS, das auf body zielt und überrascht zu sein, dass die Body-Stile des Tools nicht betroffen sind. Das iframe ist ein separates Dokument mit eigenem DOM.
  3. Externe Ressourcen, die von CSP blockiert werden. Ein <img src="https://example.com/x.png"> kann in Ihrer Vorschau gut laden, aber blockiert werden, wenn Sie denselben Code auf eine CSP-gesperrte Produktionsseite kopieren.
  4. Vergessen, dass DOMContentLoaded im iframe ausgelöst wird, nicht im Elternteil. Skripte im iframe sehen ihr eigenes document, nicht das des Tools.
  5. Setzen von sowohl allow-scripts als auch allow-same-origin in einem Sandbox-Tool, was den Zweck vollständig zunichtemacht. Browser warnen vor dieser Kombination in DevTools.

Weitere häufig gestellte Fragen

Warum funktioniert mein localStorage nicht in der Vorschau?

localStorage und sessionStorage erfordern allow-same-origin im Sandbox-Attribut. Da das mit allow-scripts zu kombinieren die Sandbox zunichtemachen würde, blockiert diese Vorschau den Speicher absichtlich. Ihr Code wird beim ersten localStorage.setItem einen SecurityError werfen. Um speicherabhängigen Code zu testen, führen Sie ihn auf einem echten Ursprung aus (zum Beispiel auf einem lokalen Dev-Server).

Welche JavaScript-Version unterstützt die Vorschau?

Was auch immer Ihr Browser unterstützt. Das iframe verwendet dieselbe JS-Engine wie die Elternseite, also bekommt ein Chrome-Benutzer V8, ein Firefox-Benutzer SpiderMonkey, ein Safari-Benutzer JavaScriptCore. Moderne Funktionen (Optional Chaining, Top-Level Await, Klassen, async/await, ES2024-Syntax) funktionieren, wenn Ihr Browser sie unterstützt. Für ältere Browser-Ziele fügen Sie transpilierte Ausgabe von Babel oder swc ein.

Kann ich externe Skripte und Stylesheets laden?

Ja für die meisten öffentlichen CDNs. <script src="https://cdn.jsdelivr.net/..."> und <link href="https://cdn.tailwindcss.com" rel="stylesheet"> funktionieren normalerweise, weil diese CDNs permissive CORS-Header setzen. Ressourcen, die Credentials erfordern oder ursprungsgesperrt sind, schlagen fehl. Das Network-Panel in den DevTools Ihres Browsers zeigt genau, welche Ressourcen geladen wurden und welche blockiert wurden.

Wie unterscheidet sich das von CodePen / JSFiddle / StackBlitz?

Das sind vollständige Code-Hosting-Dienste mit Save/Share/Fork/Collaboration-Funktionen und sie erfordern Konten. Dieses Tool ist ein Einzelseiten-Scratchpad: kein Konto, kein Speichern, kein Teilen, keine Analytik. Einfügen, Vorschau, iterieren, Tab schließen. Für etwas, das Sie behalten oder teilen möchten, ist CodePen immer noch die bessere Option.

Wird mein Code irgendwohin hochgeladen?

Nein. Das HTML / CSS / JS, das Sie einfügen, wird in <iframe srcdoc="..."> auf derselben Seite eingewickelt und in einem sandboxed eindeutigen Ursprung in Ihrem Browser gerendert. Kein Netzwerk-Aufruf transportiert Ihren Inhalt. Externe Ressourcen, auf die Ihr HTML verweist (Bilder, Skripte, Stylesheets), werden von Ihrem Browser auf die gleiche Weise abgerufen, wie sie auf jeder Webseite abgerufen würden, aber der Quellcode selbst verlässt nie die Seite.

Verwandte Tools

Code zu Bild Konverter HTML-Verkleinerer Kostenloser Markdown Previewer Online HTML-Tabellengenerator