Which Markdown flavor does the editor support?

What GFM adds, in one example

Everything from the original syntax still works: headings, emphasis, lists, links, images, blockquotes and code. GFM adds four headline features, and this snippet uses all of them:

| Feature       | Original MD | GFM |
| ------------- | :---------: | :-: |
| Tables        |     no      | yes |
| Task lists    |     no      | yes |

- [x] Draft the report
- [ ] ~~Email version~~ Share the link

https://mdeditor.tw becomes a link automatically

Every line in that block does something different, so read it element by element.

What the four extensions do

• Tables. The row of hyphens is the separator. It tells the parser that the line above is a header row, and the colons inside it set the alignment.
• Task lists. - [x] and - [ ] become ticked and unticked checkboxes. This is how a GitHub issue shows a checklist.
• Strikethrough. Double tildes cross a phrase out without deleting it, which is useful for showing a decision that changed.
• Autolinks. A bare URL becomes clickable with no bracket syntax at all.

Tip: Paste that block into the editor and compare the two panes line by line. Tables are the feature people reach for most, and the tables guide goes deep on alignment and the usual traps.

Which extensions survive where

The current picture

Extensions are exactly where portability breaks down, so it pays to know the destination before you write. These are the platforms people paste into most:

Two things to take from it

• Strikethrough and autolinks are effectively universal. Use them without thinking about it.
• Tables and task lists are developer-platform features. They are unreliable in chat, so turn a table into a short list before you send it to Discord or Slack.

If your destination is a chat client, the platform guides show what each one accepts before you hit send.

The engine: marked.js in your browser

Parsing happens in your tab

The editor renders with marked.js, a fast and widely used JavaScript parser, with its GFM option enabled. It runs entirely in your browser. That is why the preview reacts on every keystroke with no round trip, and why everything keeps working offline once the page has loaded. The generated HTML then passes through DOMPurify before it reaches the preview pane, so a pasted document containing a hostile script tag renders as harmless text.

The line-break rule that surprises people

Line breaks follow the GitHub convention. A single newline inside a paragraph counts as a space, not as a forced break. That matches how GitHub renders .md files. It does not match its comment boxes, where single newlines do break. Need a hard break? End the line with two spaces, or write <br>.

How closely it matches GitHub

What you see in the preview is what GitHub will show for your README, with one caveat. Final visual styling always comes from the destination site's CSS, so fonts, spacing and colours are theirs. The structure matches, meaning what becomes a table, a checkbox or a heading.

The GFM syntax mistakes that bite most often

Each GFM extension has one strict rule that people forget. This short block breaks all four at once:

Team roster:
| Name | Role   |
| Ana  | Editor |

- [x]Ship the beta
- [ ]Write release notes

That plan is ~cancelled~ for now.

Not one of those four constructs renders the way it was meant to.

What went wrong

• The table has no separator row, so it stays literal text with the pipes showing.
• The table is glued to the paragraph above it. A table block needs a blank line before it.
• The checkboxes have no space after the closing bracket, so the parser sees ordinary list items.
• Strikethrough used one tilde. GFM needs two.

The corrected block

Team roster:

| Name | Role   |
| ---- | ------ |
| Ana  | Editor |

- [x] Ship the beta
- [ ] Write release notes

That plan is ~~cancelled~~ for now.

A separator row needs at least three hyphens per column. Colons inside it set the alignment: :--- for left, :---: for centre, ---: for right. Column widths in your source do not have to line up, since the parser ignores extra spaces. Lining them up just keeps the raw file readable.

Tip: All four errors show up in the preview within a second or two, so watch the pane while you type. If you build tables often, the table generator writes the separator row for you.

Edge cases when your target isn't GitHub

When the destination adds its own extras

The core syntax travels perfectly. Extensions vary at the margins, as the table above shows. Some documentation systems add features GFM lacks, such as footnotes, wiki links or admonition blocks. Those blocks will not preview here. They will still publish correctly on the system that supports them, so all you lose is the live preview for those specific lines. Math is the happy exception, since the preview typesets it even though GFM never defined it.

A safe default

Stay on the common core when portability matters most, which means everything in the cheat sheet. Check the destination's own preview before you publish anything extension-heavy. Otherwise GFM remains the best default, because it is the largest syntax set that renders correctly in the most places. Still getting oriented? What Markdown is covers the fundamentals first.