QuillAid vs Dillinger and StackEdit: from Markdown to a finished document
We put the same handout through all three editors. QuillAid's visual editing handoff is its strongest advantage; the HTML exports reveal when the others make more sense.
The checklist survived the conversion. It didn't survive the next click.
Our workshop handout had two tasks: equipment checked, final review still outstanding. QuillAid's HTML kept both states. Opening that same content in QuillAid's visual editor turned the tasks into ordinary list items. The words were there; the distinction between done and unfinished was gone.
That finding belongs near the top of a comparison on QuillAid's own blog. So does the reason we'd still choose QuillAid for many short writing jobs: it lets someone take Markdown, get the article HTML, then continue editing a formatted document without learning Markdown syntax. Dillinger and StackEdit make more sense when the source itself is the thing you want to keep working on.
We used the same fictional handout in all three public tools, without connecting cloud accounts. The QuillAid and Dillinger checks began on 17 October 2026; on 18 October we repeated their conversions, inspected fresh downloads and added StackEdit. Here's what changed between the source, the exported files and the document a reviewer would actually edit.
One handout, three editors
The handout described a fictional workshop at Riverside Arts. Demonstration took 20 minutes, practice took 40, and the price was £18. A tiny JavaScript example included angle brackets and an ampersand, which needed to remain code rather than disappear into the page's markup.
This was the complete input:
# Workshop handout
This is a fictional test document for **Riverside Arts**. Bring a camera or a smartphone.
## Session plan
| Activity | Minutes |
| --- | ---: |
| Demonstration | 20 |
| Practice | 40 |
- [x] Check the equipment
- [ ] Review the final handout
Read the [Markdown specification](https://spec.commonmark.org/).
> Keep the original dates and prices when editing.
```js
const label = "<ready> & done";
```
Café notes — £18 per place.
All three previews rendered the title, bold organisation name, table, quotation and code. The table's numbers stayed right-aligned. Each preview distinguished the checked task from the unchecked one, and the link pointed to the CommonMark specification. Café, the em dash and the pound sign were intact.
There was no conversion failure to declare a winner on. The differences came when we tried to use the result. A Markdown preview, a page downloaded as HTML and a document opened for visual editing aren't interchangeable, even when they initially show the same sentences.
The sample is short enough to repeat yourself. It doesn't test an entire book, every Markdown extension or any of these tools' cloud-sync promises. If your document depends on equations, diagrams or a particular extension, add that material before deciding.
QuillAid gets you to the article HTML directly
In QuillAid's converter, we replaced the sample text, checked the preview and clicked Copy. The clipboard began:
<h1>Workshop handout</h1>
<p>This is a fictional test document for <strong>Riverside Arts</strong>.
That's an excerpt, ending before the paragraph finishes. The complete copy contained the whole handout, including the two checkbox inputs. The downloaded HTML matched that copied output exactly.
Neither included an outer document wrapper. There was no doctype, head or body to strip away before taking the article content. For a destination that accepts an HTML fragment, QuillAid hands you the relevant piece straight from the conversion screen. We didn't paste it into a specific CMS, whose own editor may remove or change some markup.
Dillinger's plain HTML download included a doctype and a full page around the content. Its body retained our handout, including both task states. There was no style block in that particular export. If you're making a standalone HTML file, the page wrapper is useful. If you're filling an article field, it's the body contents you usually want to take.
StackEdit gave us a choice. Its HTML export dialog offered Plain HTML, Styled HTML, Styled HTML with TOC, Plain text and a Jekyll site template. We selected Plain HTML and downloaded it. That file was also a fragment: headings, table, tasks and paragraphs, with no surrounding HTML page.
So QuillAid doesn't have an exclusive claim to fragment output. StackEdit can produce one too, and its export dialog has a Copy button. Our completed artifact check used the download; we didn't confirm a successful clipboard copy there. QuillAid's advantage for this job is how directly the conversion screen presents copying and downloading, without asking you to choose an export template.
The files also took different approaches to code. QuillAid kept the JavaScript inside a code element without extra spans. Dillinger added highlighting spans for the keyword and string; StackEdit added its own highlighting spans too. All three preserved the literal <ready> and & when we read the parsed code. Those extra classes matter if your existing site already styles code: exporting highlighted markup doesn't bring the matching stylesheet along with it. None of our three files included a style block.
The stronger reason to choose QuillAid is what happens next
A Markdown author may be perfectly happy with two panels: source on one side, preview on the other. The colleague reviewing the handout may just want to change a sentence, make something bold and move on.
QuillAid's Open in Editor control carried the converted content into a new guest document. It retained the headings, bold name, table contents, link, quotation and code. We could work with the formatted document rather than its Markdown notation.
In the initial handoff test, we used the Bold control to add “Bring a fully charged phone.” within the imported list. It appeared as bold text without typing asterisks around the sentence. That edit is a small example of the advantage: the reviewer doesn't need to know how Markdown represents emphasis before changing the document.
StackEdit also has formatting buttons. Its toolbar includes bold, headings, lists, tables and links, so it would be wrong to describe it as a bare text box. Its own description calls them WYSIWYG-style Markdown controls. In the workspace we used, the editable panel still showed Markdown notation beside the rendered preview. Those controls help you write the source; QuillAid's handoff lets you switch to a visually edited document.
Dillinger likewise kept the editable source beside its preview. If your next job is another source change, that continuity is convenient. If your next job is handing the wording to someone who doesn't use Markdown, QuillAid gives you a more suitable place to continue.
We'd choose QuillAid for that handoff. We wouldn't switch an established Markdown author away from their preferred editor just to get a different preview of the same table.
The checkbox loss changes our recommendation
The converter's HTML and the visual editor disagreed about the tasks. This wasn't a missing word or a slightly different bullet. The source encoded one completed task and one incomplete task; the editor no longer represented either state.
We saw the same limitation when we repeated QuillAid's handoff on 18 October. The converter and downloaded HTML still contained both checkboxes. After Open in Editor, the labels remained, but no checkbox inputs were present in the document.
For our handout, that means a reviewer could no longer tell whether the equipment check had happened. If the checklist is part of the information being handed over, we'd keep the source or use the converter's HTML instead of relying on the visually imported version.
For a piece made of headings, paragraphs, tables and quotations, the handoff was much more useful. Those were the elements we could inspect and continue editing. The distinction is worth making before you choose the tool, rather than discovering it after someone has revised the only copy.
It also explains why a screenshot of a good preview isn't enough to judge a converter. Follow the actual delivery route. In this case, conversion preserved information that a later editing step dropped.
Check the export label before promising a Word file
QuillAid's editor offered Microsoft Word .doc, described as Word-compatible HTML. That isn't a native .docx export. A recipient asking specifically for DOCX may reject a different format, regardless of whether a word processor can open it. We didn't test Microsoft Word rendering for this comparison.
PDF was labeled as a server export requiring sign-in. We converted the handout and opened it for local editing without signing in, but the PDF menu made a different access requirement clear. Anonymous editing doesn't mean every delivery option is anonymous.
Dillinger's menu offered Markdown, HTML, Styled HTML and PDF. We inspected plain HTML, not its PDF output. StackEdit's sidebar also offered PDF and Pandoc export with sponsor labels; neither was part of our completed tests. There isn't a measured PDF-quality advantage to award here.
The useful question is the recipient's requirement. For source that will return to a repository, keep Markdown. For an article field that accepts HTML, inspect the fragment. For a standalone page, include the surrounding document and whatever styling it needs. For a required Word format, check the actual extension before doing the final edit in a tool that may not deliver it.
Where Dillinger and StackEdit earn their place
Dillinger's appeal is its continuous source-and-preview workspace. Its local document list and New Document control let us move between Markdown documents without switching to a separate visual editor. Writers who review punctuation and formatting in source can stay there through export.
Its feature documentation also lists GitHub, Dropbox, Google Drive, OneDrive and Bitbucket connections, along with Vim and Emacs keyboard modes. We didn't connect those services. They're documented reasons to investigate Dillinger if your writing already lives in one of those systems, not sync results from our handout test.
StackEdit goes further into configurable Markdown publishing. The template selector we used is a practical example: you can choose plain output or an export with styling and a table of contents. Its official site describes Google Drive, Dropbox and GitHub sync, publishing to Blogger, WordPress and Zendesk, and template-based formatting. Those integrations weren't connected in our test either.
If you maintain several Markdown documents and want control over their exported presentation, StackEdit deserves a look. Its plain export retained our checklist, and its template choices covered more presentation options than the fixed QuillAid converter download. QuillAid's simpler route is helpful when those choices would be extra decisions you don't need to make.
Which one would we use for this handout?
For the article HTML alone, all three produced usable content in the specific exports we inspected. QuillAid supplied a fragment directly, StackEdit supplied one through Plain HTML, and Dillinger supplied a complete page. Their output didn't give us grounds to claim one generally converts Markdown more accurately.
For a nontechnical reviewer making wording and formatting changes, we'd use QuillAid's visual editor, while retaining the original checklist separately. The copy control and direct handoff are the reasons we'd choose it. They address the work between receiving Markdown and finishing a document, where source-editing features may be of little interest to the next person.
For a handout whose checked states must stay editable, we'd keep working in Markdown. Dillinger suits the straightforward source-and-preview job; StackEdit adds export-template choices. QuillAid's guest editor also indicated that work was saved in this browser, with sign-in for access elsewhere. We wouldn't treat that local document as a cross-device backup.
Our choice turns on who makes the next edit and where the result has to go. If the answer is “a colleague needs to polish this without touching Markdown,” QuillAid is the better fit among these tested workflows. If the answer is “we're maintaining the Markdown,” the other two have clear reasons to stay in the running.