Vergleich · Aktualisiert 2026-05-16

TaskKit's Markdown-Editor vs Dillinger.io

Beide Tools lassen dich links Markdown tippen und rechts HTML sehen. Sie unterscheiden sich deutlich darin, was neben dem Editor geladen wird, was beim Klick auf Export über das Netzwerk geht und was die Seite tut, bevor du überhaupt etwas getippt hast. Die Zusammenfassung unten ist gegen das ausgelieferte Bundle auf dillinger.io gemessen und durch Dillinger's eigene Dokumentation belegt.

Privacy, gemessen

Gemessen am 2026-05-16, frisches Chrome-Profil, keine Extensions, die Anfragen filtern. Die Zahlen gelten für die Startseite (den Editor selbst) beim ersten Paint, vor jeder Nutzeraktion.

OAuth-vermittelter Cloud-Sync ist ein vernünftiges Muster für das, was Dillinger tut. Der Kontrast besteht nicht darin, dass das Design falsch wäre, sondern darin, dass das Backend überhaupt existiert, was ein Session-Modell, OAuth-Token-Handling und einen Server-Pfad für das Dokument bedeutet. TaskKit's Markdown-Editor hat keines davon, weil nichts, was er tut, eines braucht. Mehr dazu, wie TaskKit mit deinen Daten umgeht.

Feature-Matrix

Was TaskKit's Editor hat, das Dillinger nicht hat

• Mermaid-Diagramme in der Vorschau. Fenced ```mermaid-Blöcke werden inline zu SVG gerendert. Elf Diagrammtypen funktionieren end-to-end. Die Mermaid-Library wird beim ersten Auftauchen eines Diagramms dynamisch importiert, das Bundle bleibt also klein für Nutzer, die nie eines zeichnen.
• Offline-PDF-Export. Die gesamte Pipeline (Vorschau klonen, Inline-SVGs in PNGs rastern, Off-Screen-Canvas in A4-Seiten schneiden, mit pdf-lib einbetten) läuft nur im Browser. Trenn mitten im Export das Netzwerk, und es entsteht trotzdem eine Datei.
• Handgeschriebener Renderer mit zwei Sicherheits-Layern. Jeder Text-Run geht durch HTML-Entity-Escaping, bevor er den Output-Puffer erreicht (ein wörtliches <script> in der Quelle wird zu <script>, kein ausführendes Tag). Jede URL läuft durch eine Allow-List, sodass alles außerhalb von http(s), mailto, tel, Anchor und relativen Pfaden verworfen wird, inklusive Mixed-Case JaVaScRiPt: und Splicing per Steuerzeichen.
• Kein Backend. Es gibt kein Session-Modell, keinen OAuth-Token-Speicher und keinen Server-Pfad, den das Dokument nehmen kann. Das Laden von TaskKit's Markdown-Seite löst denselben Satz Netzwerkaufrufe aus wie das Laden des Rests von TaskKit: die statischen Assets, und sonst nichts.

Wo Dillinger stärker ist

• Cloud-Sync zu fünf Anbietern. Eine Datei aus einem GitHub-Repo öffnen, bearbeiten, wieder zurückspeichern. Dasselbe mit Dropbox, Drive, OneDrive und Bitbucket. TaskKit's Markdown-Editor hat nichts Vergleichbares: dieser Flow lautet hier "das HTML rauskopieren und irgendwohin einfügen".
• Monaco-Editor-Tiefe. Multi-Cursor, Suchen / Ersetzen über den ganzen Puffer, intelligente Autovervollständigung, vim- und emacs-Keybinding-Modi. Wenn dein Muskelgedächtnis "VS Code im Browser" sagt, hat Dillinger das.
• KaTeX-Mathe-Rendering. Inline $…$ und Block $$…$$. TaskKit hat heute keine Mathematik.
• Fußnoten. [^1]-Referenznotation, mit der Definition irgendwo im Dokument. TaskKit's Renderer deckt Fußnoten noch nicht ab.
• Explizite AI-Übergabe. Dillinger's eigene Copy: "Markdown is the native language of large language models. Write in Dillinger, then feed your content directly to ChatGPT, Claude, or any LLM." TaskKit hat dafür keinen Button.

Wann du stattdessen zu Dillinger greifst

• Du musst aus dem Editor heraus Dateien in GitHub, Dropbox, Drive, OneDrive oder Bitbucket öffnen und speichern.
• Du brauchst KaTeX-Mathe-Rendering.
• Du brauchst Fußnoten.
• Du willst Monaco's Editor-Tiefe (Multi-Cursor, Autovervollständigung, vim-Modus).

Für alles andere (ein README entwerfen, eine PR-Description vorab ansehen, ein Doc mit Mermaid-Diagrammen schreiben, ein PDF exportieren, das den Tab nie verlässt) ist TaskKit's Markdown-Editor die bessere Wahl.

Was TaskKit bewusst weglässt

• Cloud-Sync. Ein "Save to GitHub"-Button ist eine großartige UX. Er erfordert aber ein Backend, irgendwo gespeicherte OAuth-Tokens und ein Session-Modell. TaskKit's Posture ist "kein Backend"; das gerenderte HTML einfügen oder ein PDF herunterladen ist der Export-Pfad.
• Syntax-Highlighting in Fenced-Code-Blöcken. Ein echter Highlighter (Prism, highlight.js, Shiki) sind 50 bis 500 KB, die an jede Seite ausgeliefert werden. Wir haben ihn weggelassen, um das Bundle klein zu halten. Das Language-Tag wird trotzdem zum Klassennamen (language-js), du kannst Highlighting also auf das kopierte HTML aufsetzen, wenn du es brauchst.
• Eingebaute "An LLM senden"-Affordances. Dass dein Entwurf an ein LLM geht, ist eine reale Aktion mit realen Konsequenzen. Der Editor ist der falsche Ort, sie hinter einem Button zu verstecken.
• Markierbarer Text im exportierten PDF. Der Export rasterisiert die Vorschau, was perfekte Styling-Treue auf Kosten von markierbarem Text liefert. Vektor-Text würde eine andere Layout-Engine erfordern.

TaskKit's Markdown-Tools ausprobieren

Methodik

Getestet am 2026-05-16 in Chrome mit frischem Profil und geleertem Cache, ohne aktive Request-Filter-Extensions. Die Netzwerkzahlen stammen aus dem Request-Log des Browsers bei einem Cold Load von https://dillinger.io/, vor jeder Interaktion. Tracker-Checks haben window.ga, window.gtag, window.dataLayer und window.google_tag_manager direkt abgefragt. Die Länge der _bsa-Queue wurde aus window._bsa_queue ausgelesen. Das Zitat "PDF export Available Server-rendered" stammt aus dem auf der Startseite ausgelieferten Willkommensdokument. Die Cloud-Sync-Endpoints und der Next.js 14 / Monaco-Stack sind in der eigenen /features-Seite des Tools und im joemccann/dillinger-Repository dokumentiert. TaskKit's Aussagen stammen aus dem Markdown-Renderer in src/lib/dev/markdown.ts und der Tool-Komponente in src/components/dev/MarkdownTool.tsx. Die Matrix wird neu geprüft, sobald eines der Tools sich wesentlich ändert.

Dillinger ist eine Marke des jeweiligen Inhabers. Diese Seite steht in keiner Verbindung zu Dillinger und wird nicht von Dillinger unterstützt.