Not every Markdown file is the same. The syntax for a heading is the same everywhere — but whether a pipe table renders, whether a fenced code block works, whether wikilinks are understood: that depends entirely on which dialect you're using and what tool is reading it.
For people who write to AI tools — prompts, knowledge bases, structured documents fed into Claude or ChatGPT — this is not a theoretical concern. The dialect you choose determines how reliably your structure lands on the other side.
A quick map of the dialects
Four dialects account for almost everything you're likely to encounter:
| Dialect | Tables | Fenced code blocks | Task lists | Extra features |
|---|---|---|---|---|
| Original Markdown (Gruber) | — | — | — | — |
| CommonMark | — | ✓ | — | Resolves ambiguities in original spec |
| GFM (GitHub) | ✓ | ✓ | ✓ | Strikethrough, autolinks |
| Obsidian | ✓ | ✓ | ✓ | Wikilinks, callouts, embedded files |
| Pandoc Markdown | ✓ | ✓ | — | Footnotes, definition lists, citations |
CommonMark is the closest thing to a formal standard — a rigorous spec that pins down the ambiguous corners of Gruber's original description. It includes fenced code blocks (triple backtick syntax), but not tables. If you need to pass structured data in a grid, CommonMark leaves you without a native way to do it.
GFM — GitHub Flavored Markdown — extends CommonMark with the features GitHub users needed: tables, task lists (- [ ]), strikethrough, and autolinks. Because GitHub is one of the largest repositories of written text on the internet, GFM has become the de facto standard for technical writing.
Obsidian-flavor adds wikilinks ([[Page Name]]), callouts (> [!NOTE]), and embedded files. These are useful inside an Obsidian vault, but have no special meaning outside it — including to AI tools, which read wikilinks as plain text.
Pandoc Markdown adds footnotes, definition lists, and citation syntax. Useful if your pipeline ends in a Word document or a PDF — but largely irrelevant for pure AI interaction.
What Claude and ChatGPT actually use
Both tools render GFM in their responses. Tables come out as tables. Code blocks get syntax highlighting. Task lists render as checkboxes. Strikethrough works. This is not a coincidence.
When you write to these tools, they don't render your markdown — they read it semantically. A ## heading signals hierarchy. A fenced code block signals: this is code, treat it differently. A table signals: here is structured, comparative data. The formatting shapes how the model interprets what you've written, even when you can't see the rendering happening.
The dialect the model outputs is also the dialect it understands most deeply. Writing in GFM means input and output speak the same language.
The case for GFM
There are three reasons GFM is the right choice for AI-first writing:
Both Claude and ChatGPT produce GFM in their responses. If you write in GFM, you can take the model's output and use it directly as input in a follow-up prompt — or save it as a document — without translation or cleanup. Input and output speak the same language. Every format mismatch you avoid is friction you'll never notice, because it never existed.
Language models learn from text. GitHub — the largest single corpus of GFM on the internet — is a foundational part of the training data behind every major AI tool. GFM syntax sits closer to the model's core understanding than any other dialect. When you write a pipe table or a fenced code block, you are using the notation the model has seen millions of times in real documents, not an edge-case format it has to interpret.
Structured data is one of the most powerful things you can pass to an AI model. A prompt that includes a table of options, parameters, or examples gives the model something to reason about with precision. CommonMark doesn't have tables. GFM does. That single feature is often worth the choice on its own.
What about other dialects?
Obsidian
If you keep your notes in Obsidian and feed them to AI tools, you are mostly fine. The wikilinks and callouts are read as plain text — they don't cause confusion, they just don't add any value in that context. Your content comes through. Obsidian-flavor is GFM-compatible at the core, so the basic structures all work.
Pandoc Markdown
If you need footnotes or definition lists — formats that appear in Pandoc Markdown — current AI tools will understand the content but won't treat those elements specially. It is not a problem; it's just not a feature you'll get leverage from in a plain AI chat context. Where Pandoc earns its place is in export pipelines: markdown to Word, markdown to PDF. For that, it's excellent.
CommonMark only
Using strict CommonMark means giving up tables. For many documents this doesn't matter at all. But if you're passing structured comparisons, option lists, or parameter descriptions — the most common things people send to AI tools — you'll want GFM.
The recommendation
Write in GFM
Use tables for structured data. Use fenced code blocks with a language tag (```python, ```json). Use ## headings to give your prompts clear sections. Use task lists when you want the model to track or produce sequential steps.
You don't need a plugin or a special editor. Any Markdown editor that supports GFM — VS Code, Obsidian, Typora, or a plain .md file — is enough. The point is consistency: same dialect in, same dialect out, with no friction in between.
If you already write in Obsidian, keep writing in Obsidian. The GFM core is already there. If you're starting fresh and choosing deliberately — GFM is the clear choice for AI workflow.
Further reading: What is Markdown? · How AI interfaces break the format they run on · Plain text, formatted — what AI-ready really means