HTML statt Markdown: Warum KI-Outputs im Browser besser funktionieren

Markdown ist ein Relikt aus einer Ära, in der jedes Token zählte. Als GPT-4 mit einem Kontextfenster von 8.192 Tokens an den Start ging, war die Entscheidung für Markdown gegenüber HTML schlicht ökonomisch: weniger Tokens, gleiche Struktur, kein Overhead. Thariq Shihipar, Mitglied des Claude-Code-Teams bei Anthropic, argumentiert nun öffentlich, dass dieses Kalkül heute nicht mehr stimmt — und liefert mit 20 konkreten Demos den Praxisbeweis. Simon Willison, einer der bekanntesten KI-Praktiker im englischsprachigen Raum, hat Shihipars These aufgegriffen und direkt getestet: Er bat GPT-5.5 per Kommandozeile, einen Linux-Sicherheitsexploit als interaktive HTML-Seite zu erklären — mit SVG-Diagrammen, farblich kodierten Befunden und seiteninterner Navigation. Das Ergebnis war, in Willisons eigenen Worten, "pretty good". Was banal klingt, hat weitreichende Konsequenzen für jeden, der KI täglich als Wissens- und Analyse-Werkzeug nutzt. Der Wechsel von Markdown zu HTML als bevorzugtem Output-Format ist kein Luxus mehr — er ist eine Frage der Informationsdichte, die du aus jedem Prompt herausholen kannst. Dieser Artikel zeigt dir, warum das so ist, wann der Wechsel sich lohnt, wo die Fallstricke liegen und wie du es sofort in deinen Workflow integrierst.

Warum Markdown seinen Thron verliert

Die Vorherrschaft von Markdown bei KI-Outputs war nie eine Design-Entscheidung — sie war ein Workaround. Simon Willison beschreibt es direkt: Er habe sich seit den GPT-4-Tagen angewöhnt, fast alles in Markdown anzufordern, weil das 8.192-Token-Limit von GPT-4 die Token-Effizienz von Markdown gegenüber HTML extrem wertvoll machte. HTML mit seinen öffnenden und schließenden Tags, Attributen und verschachtelten Strukturen verbraucht schlicht mehr Tokens als äquivalentes Markdown — Schätzungen aus der Branche sprechen von einer typischen Ersparnis von 20 bis 30 Prozent für Markdown gegenüber komplexem HTML.

Dieses Argument ist heute weitgehend entkräftet. Moderne Frontier-Modelle arbeiten mit Kontextfenstern, die regelmäßig bei 128.000 Tokens und darüber liegen. Der relative Overhead von HTML fällt in dieser Größenordnung kaum ins Gewicht — zumal der eigentliche Mehrwert, den HTML liefert, in keinem Verhältnis zu den zusätzlichen Token-Kosten steht. Ja, die Generierung von umfangreichem HTML kostet proportional mehr als Markdown. Aber was du dafür zurückbekommst, ist qualitativ eine andere Kategorie von Output.

Der Kernunterschied liegt in der Ausdrucksmächtigkeit des Formats. Markdown kann Überschriften, fettgedruckten Text, Code-Blöcke und einfache Listen darstellen. HTML kann das alles — und zusätzlich SVG-Vektorgrafiken direkt einbetten, interaktive JavaScript-Widgets ausführen, Farbkodierungen nach Schweregrad setzen, Akkordeon-Menüs für komplexe Inhalte aufbauen und seitenintterne Anker-Navigation ermöglichen. Für reine Textzusammenfassungen ist Markdown weiterhin das richtige Werkzeug. Aber sobald du eine KI bittest, etwas zu erklären, zu analysieren oder zu visualisieren — also genau die Aufgaben, bei denen Kontext und Struktur den Verständnisunterschied machen — spielt HTML in einer anderen Liga.

Shihipar formuliert das bei Willison so: Wenn du Claude um eine Erklärung in HTML bittest, kann es SVG-Diagramme einfügen, interaktive Widgets, seitenintterne Navigation und alle möglichen anderen Wege, die Information angenehmer navigierbar zu machen. Das ist keine Marketing-Formulierung — das ist eine präzise Beschreibung dessen, was technisch möglich wird, sobald du das Format-Constraint aufhebst.

Der Praxistest: Ein Linux-Exploit als interaktive Erklärung

Abstrakte Argumente überzeugen weniger als ein funktionierendes Beispiel. Willison hat genau diesen Test gemacht und das Ergebnis ist öffentlich einsehbar. Er hat den Inhalt von copy.fail — einer Seite, die einen realen Linux-Kernel-Exploit zur Privilege Escalation (CVE-2026-31431) beschreibt, inklusive verschleiertem Python-Proof-of-Concept — direkt per Kommandozeile an GPT-5.5 übergeben. Der Prompt war bewusst instruktiv formuliert:

curl https://copy.fail/exp | llm -m gpt-5.5 -s 'Explain this code in detail. 
Reformat it, expand out any confusing bits and go deep into what it does 
and how it works. Output HTML, neatly styled and using capabilities of HTML 
and CSS and JavaScript to make the explanation rich and interactive and as 
clear as possible'

Das Ergebnis war eine dark-themed HTML-Seite mit zweispaltiger Ansicht: Links eine High-Level-Zusammenfassung des Exploits mit nummerierten Schritten, rechts eine strukturierte Tabelle mit Mustern und deren Zwecken — inklusive einer gelb hervorgehobenen Safety Note. Der Exploit nutzt das algif_aead-Modul des Linux-Kernels (AF_ALG), Pipes und splice(), um Bytes in den Page-Cache eines privilegierten Executables zu schreiben, ohne jemals write() aufzurufen. Das klingt abstrakt — in der generierten HTML-Seite wird dieser Mechanismus schrittweise aufgedröselt, mit konkreten Systemcalls und ihrer Funktion im Exploit-Ablauf.

Willisons selbstkritische Anmerkung ist dabei methodisch wertvoll: Er hätte im Prompt stärker betonen sollen, den Exploit selbst zu erklären statt des Python-Wrappers drum herum. Das ist kein Fehler des Formats — es ist ein Prompt-Engineering-Problem, das bei Markdown genauso aufgetreten wäre. Die Lektion: HTML als Format entbindet dich nicht davon, deinen Prompt präzise zu formulieren. Es multipliziert lediglich die Qualität dessen, was du bereits gut formulierst.

Für Developer und Security-Analysten ist dieses Beispiel besonders instruktiv. Code-Reviews, Exploit-Analysen, Architektur-Dokumentationen — das sind genau die Anwendungsfälle, bei denen strukturierte, farbkodierte, interaktive Outputs einen messbaren Mehrwert gegenüber einer Markdown-Ausgabe liefern, die man danach noch manuell in ein Dokument kopiert.

So setzt du es um: HTML-Prompts Schritt für Schritt

Der Einstieg ist einfacher als er klingt. Du brauchst kein neues Tool, keine neue Plattform — du änderst lediglich die Output-Instruktion in deinen bestehenden Prompts. Hier ist der praktische Workflow:

1. Format explizit anfordern: Füge am Ende deines Prompts eine klare Instruktion hinzu: "Output HTML, neatly styled, using CSS and JavaScript for interactivity." Ohne diese Anweisung fällt das Modell in die Markdown-Default-Einstellung zurück. Das gilt für Claude genauso wie für GPT-5.5.
2. Interaktivitäts-Dimensionen spezifizieren: Sage dem Modell, welche HTML-Fähigkeiten du nutzen willst. Beispiel: "Use color-coded severity levels, collapsible sections for details, and SVG diagrams where helpful." Je präziser du das Format beschreibst, desto gezielter nutzt das Modell die Möglichkeiten von HTML und CSS.
3. Output als .html-Datei speichern: Statt den Output in deinen Chat zu kopieren, leite ihn direkt in eine Datei: llm -m gpt-5.5 -s "[dein System-Prompt]" < input.txt > output.html. Dann öffne die Datei im Browser. Das ist der schnellste Weg, um die volle Wirkung zu sehen.
4. Für Code-Reviews: Diff-spezifische Prompts nutzen: Shihipar schlägt ein Template vor, das direkt für Pull-Request-Reviews optimiert ist: "Help me review this PR by creating an HTML artifact that describes it. I'm not very familiar with the streaming/backpressure logic so focus on that. Render the actual diff with inline margin annotations, color-code findings by severity and whatever else might be needed to convey the concept well." — Dieses Prompt-Muster liefert einen Überblick, der in Markdown strukturell nicht möglich wäre.
5. In Claude-Artifacts direkt verwenden: Claude in der Web-Oberfläche rendert HTML-Artifacts direkt im Chat. Frage explizit nach einem "HTML Artifact" statt einer Markdown-Antwort. Das Ergebnis erscheint als interaktives Preview-Fenster rechts neben dem Chat — kein separater Browser-Tab nötig. Anthropic nutzt dabei iFrame-Sandboxing mit Full-Site Process Isolation, um XSS-Risiken durch KI-generierten Code zu minimieren.

Ein vollständiges Prompt-Template für technische Erklärungen sieht so aus:

ROLLE: Du bist ein technischer Erklärer mit Fokus auf Verständlichkeit.
KONTEXT: [Füge hier deinen Code / dein Dokument / deine Frage ein]
AUFGABE: Erkläre das folgende Konzept detailliert und vollständig.
OUTPUT-FORMAT: Erstelle eine vollständige HTML-Seite mit:
- Dark/Light Theme Toggle via JavaScript
- Farbkodierte Abschnitte nach Schweregrad oder Wichtigkeit
- SVG-Diagramm für Datenflüsse oder Architekturen
- Akkordeon-Sektionen für Detail-Inhalte
- Inline-Kommentare in Code-Blöcken

Die typischen Fallstricke

HTML als Output-Format hat drei konkrete Probleme, die du kennen solltest — bevor sie dich im falschen Moment erwischen.

• XSS-Risiken durch KI-generierten Code: Wenn du HTML-Output von einem LLM direkt in eine bestehende Webanwendung einbettest, öffnest du potenzielle Cross-Site-Scripting-Angriffsvektoren. Anthropic begegnet diesem Problem in seinen Artifacts mit iFrame-Sandboxing und Full-Site Process Isolation — aber das ist die Lösung für ihre kontrollierte Umgebung. Wenn du KI-generierten HTML-Code in deine eigene App integrierst, musst du sanitisieren oder einen eigenen Sandbox-Layer implementieren. Lösung: Nutze HTML-Output nur als standalone Datei im Browser oder in kontrollierten Artifact-Umgebungen — niemals unkontrolliert als innerHTML in bestehenden Apps.
• Token-Kosten skalieren mit Komplexität: Eine einfache Markdown-Zusammenfassung kostet deutlich weniger als eine vollständige HTML-Seite mit JavaScript und SVG. Für kurze, häufig wiederholte Aufgaben — etwa das Zusammenfassen von Meeting-Notizen oder das Formatieren von Listen — ist Markdown nach wie vor das wirtschaftlichere Format. Der Break-even liegt dort, wo die Qualität der Erklärung die zusätzlichen API-Kosten rechtfertigt. Lösung: Setze HTML gezielt für komplexe, einmalige Analyse- und Erklärungs-Aufgaben ein — nicht als universellen Default.
• Schlechte HTML-Qualität bei unspezifischen Prompts: Wenn du nur "Output HTML" schreibst ohne weitere Spezifikation, bekommst du oft generisches, schlecht strukturiertes HTML ohne wirklichen Mehrwert gegenüber Markdown. Das Modell braucht explizite Hinweise darauf, welche HTML-Fähigkeiten es nutzen soll. Lösung: Nutze das Template-Format aus dem Schritt-für-Schritt-Abschnitt oben. Je präziser deine Format-Instruktion, desto höher die Qualität des Outputs.

Was sich rechnet: ROI des Format-Wechsels

Der ROI-Rechner für diesen Workflow-Wechsel hängt stark vom Anwendungsfall ab. Hier zwei konkrete Szenarien, die du direkt auf deinen Alltag übertragen kannst:

Szenario 1 — Code-Review-Dokumentation: Ein Developer verbringt manuell etwa 90 Minuten damit, einen komplexen Pull Request zu dokumentieren, mit Schweregrad-Markierungen und Erklärungen für das Team (bei einem angenommenen Stundensatz von 80 Euro: 120 Euro). Mit einem HTML-Prompt-Template wie dem von Shihipar dauert das initiale Prompting 10 Minuten, die Nachbearbeitung weitere 15 Minuten, dazu kommen API-Kosten von etwa 0,50 bis 1,50 Euro je nach Modell und Dokumentgröße. Gesamtkosten: circa 35 Euro. Das entspricht einem Einsparfaktor von mehr als 3x — bei gleichzeitig höherer Darstellungsqualität durch Farbkodierung und Inline-Annotationen.

Szenario 2 — Technische Dokumentation für Onboarding: Eine interaktive HTML-Erklärung einer Systemarchitektur, die ein neuer Mitarbeiter selbst navigieren kann, ersetzt mehrstündige Einarbeitungssessions. Manuell: 3 Stunden Erstellung plus Präsentation (je Runde), also 240 Euro pro Onboarding-Runde. Mit HTML-Output: 20 Minuten Prompting und Nachbearbeitung plus API-Kosten, also etwa 30 Euro — und das Dokument ist wiederverwendbar ohne zusätzliche Präsentationszeit.

Der entscheidende Punkt ist nicht die reine Zeitersparnis, sondern der qualitative Sprung: Eine HTML-Seite, die ein Entwickler im Browser öffnet und selbst erkundet, transportiert komplexe technische Zusammenhänge anders als ein linearer Markdown-Text. Für Wissenstransfer, Dokumentation und technische Analyse ist das ein strukturelles Argument, kein Effizienz-Argument.

So What? Der Impuls für deinen Workflow

Der Kern von Shihipars Argument ist kein technischer Hack — es ist eine Neukalibrierung einer Gewohnheit, die aus einer Constraint-Ära stammt, die vorbei ist. Wenn du heute noch reflexartig "erkläre mir das in Markdown" in deine Prompts schreibst, folgst du einer Konvention, die für GPT-4 mit 8k-Token-Limit sinnvoll war. Für aktuelle Modelle mit Kontextfenstern jenseits der 100.000-Token-Grenze gilt diese Logik nicht mehr.

Die strategische Implikation ist größer als der einzelne Prompt. Wer HTML als Output-Format begreift, beginnt, KI-Outputs als eigenständige Artefakte zu denken — nicht als formatierten Text, den man in ein anderes Tool kopiert, sondern als fertige, interaktive Dokumente, die direkt weiterverwendbar sind. Das verändert den Workflow fundamental: Weniger Copy-Paste in Notion oder Confluence, mehr direkt distribuierbare HTML-Dateien, die jeder im Team im Browser öffnen kann.

Für Teams, die KI bereits intensiv für Dokumentation, Code-Reviews oder technische Analysen nutzen, ist das ein konkreter Hebel. Für alle anderen ist es ein Einstiegspunkt, der ohne Infrastruktur-Aufwand funktioniert: Du brauchst keinen neuen Stack, kein neues Abonnement. Du brauchst eine geänderte Prompt-Instruktion.

Im Kontext des EU AI Act ist diese Entwicklung auch regulatorisch nicht irrelevant. Die GPAI-Regeln, die seit August 2025 in Kraft sind, verlangen Transparenz über KI-generierte Inhalte. Interaktive HTML-Artefakte, die klar als KI-generiert gekennzeichnet sind und Quellen strukturiert anzeigen können, erfüllen diese Anforderung leichter als rohe Markdown-Outputs in Chat-Interfaces. Wer für sein Unternehmen KI-Outputs in interne Dokumentationen integriert, sollte diesen Aspekt mitdenken.

Fazit: Ein kleiner Prompt-Wechsel mit großer Wirkung

Thariq Shihipars Argument ist überzeugend, weil es praktisch und direkt überprüfbar ist. Du musst keiner theoretischen These vertrauen — du kannst heute Abend deinen nächsten Analyse-Prompt um den Satz "Output HTML, neatly styled, with interactive elements" erweitern und das Ergebnis mit deiner üblichen Markdown-Ausgabe vergleichen. Die Differenz spricht für sich.

Das bedeutet nicht, Markdown zu verbannen. Für schnelle Antworten, Textzusammenfassungen und strukturierten Output, der in andere Tools fließt, bleibt Markdown das richtige Format. Aber für Erklärungen, Analysen, Code-Reviews und Dokumentationen — also genau die Aufgaben, bei denen Struktur und Visualisierung den Unterschied zwischen "verstanden" und "noch mal erklärt" machen — ist HTML das stärkere Werkzeug.

Simon Willisons Eingeständnis, dass er seine eigene Gewohnheit durch Shihipars Stück überdacht hat, ist dabei das stärkste Signal. Willison ist jemand, der KI-Tools täglich und professionell einsetzt und dokumentiert. Wenn er einen Workflow-Wechsel öffentlich ankündigt, lohnt es sich, das ernst zu nehmen. Der nächste Schritt liegt bei dir: Öffne deinen nächsten komplexen Prompt und ergänze die Output-Instruktion. Mehr braucht es nicht, um zu sehen, was HTML als KI-Output-Format tatsächlich kann.