Comparison · Updated 2026-05-16

TaskKit's Markdown editor vs Dillinger.io

Both tools let you type Markdown on the left and see HTML on the right. They diverge sharply on what loads alongside the editor, what crosses the network when you hit Export, and what the page does before you've typed anything. The summary below is measured against the served bundle on dillinger.io and grounded in Dillinger's own documentation.

Privacy, measured

Measured 2026-05-16, fresh Chrome profile, no extensions filtering requests. Numbers are for the home page (the editor itself) on first paint, before any user action.

OAuth-mediated cloud sync is a reasonable pattern for what Dillinger is doing. The contrast isn't that the design is wrong, it's that the backend exists at all, which means a session model, OAuth token handling, and a server path for the document. TaskKit's Markdown editor doesn't have one because nothing it does requires one. More about how TaskKit handles your data.

Feature matrix

What TaskKit's editor has that Dillinger doesn't

• Mermaid diagrams in the preview. Fenced ```mermaid blocks render to SVG inline. Eleven diagram types work end-to-end. The Mermaid library is dynamically imported the first time a diagram appears, so the bundle stays small for users who never draw one.
• Offline PDF export. The whole pipeline (clone the preview, rasterise inline SVGs into PNGs, slice the off-screen canvas into A4 pages, embed them with pdf-lib) is browser-only. Disconnect the network mid-export and it still produces a file.
• Hand-written renderer with two security layers. Every text run goes through HTML-entity escaping before reaching the output buffer (a literal <script> in the source becomes <script>, not an executing tag). Every URL goes through an allow-list, so anything outside http(s), mailto, tel, anchors, and relative paths is dropped, including mixed-case JaVaScRiPt: and control-character splicing.
• No backend. There's no session model, no OAuth token storage, and no server path the document can take. Loading TaskKit's Markdown page makes the same set of network calls as loading the rest of TaskKit: the static assets, and nothing else.

Where Dillinger is stronger

• Cloud sync to five providers. Open a file from a GitHub repo, edit it, save it back. Same with Dropbox, Drive, OneDrive, and Bitbucket. TaskKit's Markdown editor has nothing equivalent: that flow is "copy the HTML out and paste it wherever".
• Monaco editor depth. Multi-cursor, find / replace across the buffer, intelligent autocompletion, vim and emacs keybinding modes. If your muscle memory is "VS Code in the browser", Dillinger has it.
• KaTeX math rendering. Inline $…$ and block $$…$$. TaskKit has no math today.
• Footnotes. [^1] reference notation, with the definition anywhere in the document. TaskKit's renderer doesn't cover footnotes yet.
• Explicit AI hand-off. Dillinger's own 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 doesn't have a button for that.

When to reach for Dillinger instead

• You need to open and save files in GitHub, Dropbox, Drive, OneDrive, or Bitbucket from the editor itself.
• You need KaTeX math rendering.
• You need footnotes.
• You want Monaco's editor depth (multi-cursor, autocompletion, vim mode).

For everything else (drafting a README, previewing a PR description, authoring a doc with Mermaid diagrams, exporting a PDF that never leaves the tab) TaskKit's Markdown editor is the better fit.

What TaskKit deliberately leaves out

• Cloud sync. A "Save to GitHub" button is a great UX. It also requires a backend, OAuth tokens stored somewhere, and a session model. TaskKit's posture is "no backend"; pasting the rendered HTML or downloading a PDF is the export path.
• Syntax highlighting in fenced code blocks. A real highlighter (Prism, highlight.js, Shiki) is 50 to 500 KB shipped to every page. We left it out to keep the bundle small. The language tag still becomes a class name (language-js), so you can layer highlighting on top of the copied HTML if you need it.
• Built-in "send to LLM" affordances. Your draft going to an LLM is a real action with real consequences. The editor is the wrong place to obscure it behind a button.
• Selectable text inside the exported PDF. The export rasterises the preview, which gives perfect styling fidelity at the cost of selectable text. Vector text would need a different layout engine.

Try TaskKit's Markdown tools

Methodology

Tested 2026-05-16 in Chrome with a fresh profile and cache cleared, no request-filtering extensions active. Network counts were taken from the browser's request log on a cold load of https://dillinger.io/, before any interaction. Tracker checks queried window.ga, window.gtag, window.dataLayer, and window.google_tag_manager directly. The _bsa queue length was read from window._bsa_queue. The "PDF export Available Server-rendered" quote is from the welcome document shipped on the home page. Cloud-sync endpoints and the Next.js 14 / Monaco stack are documented in the tool's own /features page and the joemccann/dillinger repository. TaskKit's claims come from the Markdown renderer in src/lib/dev/markdown.ts and the tool component in src/components/dev/MarkdownTool.tsx. The matrix will be re-checked when either tool changes materially.

Dillinger is a trademark of its respective owner. This page is not affiliated with or endorsed by Dillinger.