WYSIWYG steht für “What You See Is What You Get” – auf Deutsch sinngemäß “Was du siehst, ist was du bekommst”. Gemeint ist ein Editor, in dem der Inhalt bereits während der Bearbeitung so dargestellt wird, wie er später beim Leser ankommt. Statt mit Tags, Markdown oder Befehlen zu hantieren, sieht der Redakteur direkt: Diese Überschrift ist 32 px groß, dieses Bild ist linksbündig, dieser Absatz ist kursiv. Genau aus diesem Grund sind WYSIWYG-Editoren das Standard-Werkzeug in fast jedem Content-Management-System, in E-Mail-Marketing-Tools und in modernen Page-Buildern: Sie senken die Einstiegshürde drastisch und machen Content-Pflege ohne HTML-Kenntnisse möglich.
Funktionsweise
Im Hintergrund arbeitet jeder WYSIWYG-Editor mit zwei Schichten:
- Eine bearbeitbare Darstellungsschicht (meist ein HTML-
contenteditable-Bereich oder ein eigenes Render-Layer), in der der Nutzer formatieren kann - Eine strukturierte Speicherform (HTML, Block-JSON oder ein proprietäres Format), die hinter den Kulissen gepflegt wird
Beim Klick auf “Fett” wird der markierte Text intern in <strong>…</strong> (oder einen Block-Token) verpackt, in der Oberfläche aber sofort visuell als fett dargestellt. Beim Speichern landet die strukturierte Form in der Datenbank, beim Rendern wird sie über das CMS-Theme wieder zu HTML.
Bekannte WYSIWYG-Editoren
| Editor | Eingesetzt in | Charakteristikum |
|---|---|---|
| Gutenberg | WordPress (seit 5.0) | Block-basiert, jeder Inhalt ist ein eigener Block |
| TinyMCE | Drupal, Joomla, Confluence | Klassischer “Word-Style” Toolbar-Editor |
| CKEditor 5 | Atlassian, viele SaaS-Tools | Modular, Real-Time-Collab-fähig |
| Quill | Slack, LinkedIn-Posts | Schlanker, gut für Embed in eigene Apps |
| ProseMirror | Notion, New York Times | Sehr flexibel, Schema-getriebenes Document Model |
| Elementor / Divi | WordPress Page Builder | Drag-and-Drop ganzer Seitenlayouts |
| Block Kit / Editor.js | moderne Headless-CMS | JSON-basiertes Block-Modell |
Vor- und Nachteile
Vorteile
- Geringe Einstiegshürde: Redakteure ohne HTML-Wissen können direkt loslegen
- Schnelles Visualisieren: Layout-Entscheidungen werden sofort sichtbar
- Vorlagenarbeit: Wiederverwendbare Blöcke und Templates beschleunigen die Pflege
- Konsistenz: Wenn das CMS-Theme die Block-Styles vorgibt, bleiben Schriften, Farben und Abstände markenkonform
- Medien-Workflow: Bilder, Videos und Embeds lassen sich per Drag-and-Drop einbinden
Nachteile
- Verstecktes HTML kann verschmutzen: Inline-Styles, leere
<span>-Tags und unnötige<br>-Folgen sammeln sich bei intensiver Nutzung an - Code-Block-Tüftler stoßen an Grenzen: Wer komplexe semantische Strukturen braucht, schaltet meist doch in den Quelltext-Modus um
- Vendor-Lock-in: Proprietäre Block-Formate (Elementor, Divi) sind später schwer in andere Systeme zu migrieren
- Performance-Risiko: Schwergewichtige Editoren wie Elementor können die Frontend-Performance belasten, wenn ihr Render-Output zu generisch ist
- Style-Drift: Wenn Redakteure individuell formatieren statt vordefinierte Blöcke zu nutzen, leidet die visuelle Konsistenz
WYSIWYG vs. Markdown vs. Block-Editor
| Ansatz | Stärke | Schwäche |
|---|---|---|
| WYSIWYG (klassisch) | Schnelle visuelle Bearbeitung | “Schmutziges” HTML, Style-Drift |
| Markdown | Plain-Text, versionierbar, klar | Lernkurve für Nicht-Techniker |
| Block-Editor (Gutenberg, Notion) | Strukturierte Blöcke + visuelles Feedback | Komplexer, mehr Klicks |
Moderne CMS-Welten bewegen sich klar in Richtung Block-Editor – als Hybrid aus Markdown-Sauberkeit und WYSIWYG-Komfort.
Tipps für den produktiven Einsatz
- Block- und Style-Vorlagen definieren: Statt freier Inline-Formatierung lieber verbindliche Blöcke (Hero, CTA, Quote, Akkordeon)
- Toolbar reduzieren: Nur Optionen anbieten, die der Redakteur wirklich braucht – jede zusätzliche Option ist eine potenzielle Stil-Abweichung
- Style-Whitelist erzwingen: Inline-
color,font-family, beliebige Schriftgrößen ausblenden, damit die CI eingehalten wird - Quelltext-Modus erlauben, aber sparsam: Erfahrene Redakteure schätzen ihn, neue Nutzer richten dort schnell Chaos an
- Output regelmäßig auditieren: Manche Editoren produzieren überflüssige Tags; ein Cleanup-Job oder ein DOM-Linter hilft
Häufige Fragen zu WYSIWYG
Ist Gutenberg ein WYSIWYG-Editor? Im weiteren Sinne ja – die Vorschau ist nahe am Endergebnis. Technisch ist Gutenberg ein Block-Editor, der WYSIWYG-Prinzipien mit strukturierten Blöcken verbindet.
Können WYSIWYG-Editoren auch barrierefrei sein?
Ja, wenn sie semantisch sauberes HTML produzieren (richtige Headline-Hierarchie, alt-Texte für Bilder, Tastatur-Bedienbarkeit). Editoren wie CKEditor 5 oder Gutenberg liefern hier solide Defaults; der Schein-Editor “Elementor” produziert ohne sorgfältige Theme-Konfiguration leicht problematisches Markup.
Was passiert, wenn ich vom WYSIWYG-Editor in den Quelltext wechsle? Bei den meisten Editoren bleibt der Inhalt erhalten, manche normalisieren das HTML jedoch (Reformatierung, Entfernen unbekannter Attribute). Vor dem Wechsel zwischen den Modi immer einen Backup-Stand sichern.
Sind WYSIWYG-Editoren SEO-tauglich? Ja – sie sind nur ein Werkzeug. Entscheidend ist, ob das CMS-Theme korrektes HTML (Heading-Struktur, Schema-Markup, Metadaten) rendert. Der Editor selbst beeinflusst SEO nicht direkt.
Brauche ich noch HTML-Kenntnisse, wenn der Editor visuell ist? Für die Standardpflege nicht. Für Fehlerbehebung (verbogenes Layout, kaputte Listen, unsaubere Verschachtelung) sind HTML-Grundlagen aber jederzeit hilfreich.
Fazit
WYSIWYG-Editoren sind das Bindeglied zwischen Redaktion und Technik – richtig konfiguriert, ermöglichen sie schnelles, konsistentes Publishing ohne HTML-Wissen. Falsch konfiguriert (zu viele Freiheitsgrade, kein Style-Korsett) erzeugen sie schnell Style-Wildwuchs und SEO-Probleme. In jedem CMS-Projekt, das wir umsetzen, definieren wir die Editor-Konfiguration im Sinne der Redaktion und der Wartbarkeit – sprich uns für ein unverbindliches Beratungsgespräch gerne an.