Why the same Markdown renders differently everywhere
Markdown is not a program. It is a convention for writing plain text, and every app that displays it brings its own parser: software that reads your characters and decides what to build. Nothing forces two parsers to agree.
- Core Markdown behaves the same everywhere; the extended third of the language is where apps split.
- Some apps keep your
.mdfile, some keep only the text, and some throw the symbols away. - The matrix below compares eleven platforms on tables, task lists, footnotes, code and storage.
- Four apps get a page of their own, because a yes-or-no answer does not describe them properly.
Choice one: which flavor the app targets
Most modern tools follow CommonMark plus the GitHub Flavored Markdown extensions, which is where tables, task lists and strikethrough come from. Chat apps implement a small hand-picked subset instead. A table inside a one-line message is a design problem, not a feature.
Choice two: which parser library does the work
The second choice is the library itself, and how old it is. GitHub, Obsidian and this site's editor all claim GFM support, yet they differ at the edges. Footnote handling, HTML passthrough, how many spaces nest a list, whether a bare URL becomes a link: each is a small decision made by somebody else.
Why your syntax is rarely the problem
So the characters you type are almost never at fault. Core Markdown behaves identically everywhere, and platforms split apart on the extended elements, roughly a third of the language. The Markdown syntax hub lays out which elements sit in which layer, and what Markdown is covers how the format grew so many dialects in the first place.
Apps that store Markdown, and apps that only accept it
This is the most useful idea on the page, and it has nothing to do with syntax. Before asking whether an app supports Markdown, ask what it does with your characters after you type them. There are three answers.
Group one: Markdown is the storage format
Obsidian, VS Code, and every static site generator (Hugo, Jekyll, Astro, Eleventy, MkDocs, Docusaurus) keep real .md files on a disk you control. The symbols stay in the file, so you can grep them, track them in Git, open them in any editor, and move the folder elsewhere in an afternoon. Files in a GitHub or GitLab repository belong here too.
Group two: Markdown is only the input method
Notion and Slack read your characters, build their own internal objects, then throw the symbols away. Type ## in Notion and it becomes a heading block. The hashes are gone, and there is no source view, because there is no source. You are using Markdown as a keyboard shortcut rather than writing it.
Group three: the source survives, but not as a file
Discord, Reddit, and comments on GitHub and GitLab store your raw text in a database and re-render it on every view. Edit a message and your asterisks come back. That is friendlier than group two, but the text lives inside one service and leaves only by copy and paste.
Why this beats the feature list
Portability, versioning and longevity all follow from the group, not from how many elements an app renders. A group-one app can have a worse table implementation than Notion and still be the safer home for five years of notes.
Tip: Work out an app's group before you commit a project to it. Getting out of group two is always harder than getting in, and nobody discovers that until the day they want to leave.
The support matrix
Eleven platforms against the four elements that most often decide whether a document survives a move, plus the storage question. Partial means "depends on your client, version or settings."
Eleven platforms, five questions
| Platform | Tables | Task lists | Footnotes | Code highlighting | Stores as .md |
|---|---|---|---|---|---|
| Notion | Partial, own table block only | Yes, as to-do blocks | No | Yes | No |
| Obsidian | Yes | Yes | Yes | Yes | Yes |
| Discord | No | No | No | Yes, with a language label | No, kept as message text |
| Yes | No | No | No, monospace only | No, kept as post text | |
| GitHub | Yes | Yes | Yes | Yes | Yes, for repo files |
| GitLab | Yes | Yes | Yes | Yes | Yes, for repo files |
| Slack | No | No | No | No, monospace only | No |
| Microsoft Teams | No | No | No | Partial, via the code snippet tool | No |
| VS Code preview | Yes | Yes | Partial, needs an extension | Yes | Yes |
| Jupyter | Yes | Partial, JupyterLab renders them | Partial, varies by version | Yes | No, cells live in .ipynb |
| Ghost | Yes, in the Markdown card | Partial | Partial | Partial, theme dependent | Partial, source kept inside the post |
Read the columns, not the rows
- Tables tell a document tool from a chat tool faster than anything else in the grid.
- Footnotes separate the serious writing tools from everything else.
- Code highlighting is the one column chat apps sometimes win, because short snippets are what they were built for.
- Stores as .md is the column that matters in five years, and the only one you cannot fix later.
Anything not listed is predictable from its category. Developer tools and note apps sit near Obsidian, chat apps near Slack, and block-based workspaces near Notion.
Writing Markdown that survives the move
If a document might end up somewhere other than where you drafted it, a few habits remove most of the pain. None of them cost anything at writing time.
Six habits worth adopting
- Stay in core syntax for anything you will paste into chat. Headings, bold, italic, lists, links and code fences travel everywhere. Tables, footnotes and task lists do not.
- Avoid raw HTML. It works on static sites, is sanitised on GitHub, and is shown as literal text or stripped everywhere else.
- Do not nest more than two levels deep. Nested list indentation is the least portable part of the language, and four spaces per level is safest.
- Never use two trailing spaces for a line break. They are invisible, editors strip them, and half the platforms above ignore them. Use a blank line.
- Keep images beside the file and use relative paths. Absolute paths to your own machine break the moment anyone else opens the document.
- Draft where the source is kept. Write in a group-one tool and paste into group two, never the reverse.
Two tools that catch the problems early
Before pasting a long document somewhere unforgiving, check it in the Markdown viewer. To move content out of a rich text editor, HTML to Markdown converts a pasted page back into clean source. The rest of the free Markdown tools handle conversion, tables and contents lists.
The Markdown editor on our homepage renders GitHub Flavored Markdown, which is a fair proxy for how GitHub, GitLab and most modern tools will treat your file.
Where to go for the detail
The matrix answers "does it work". Four platforms need more than that, because a yes-or-no cell hides the behaviour that actually trips people up.
Pick the page by the question you have
- Why does
>make a toggle instead of a blockquote? That question, along with which shortcuts convert as you type and what survives a.mdimport or export, is the ground Markdown in Notion covers. - Which of my clever features will not travel? Markdown in Obsidian looks at the closest thing to a pure Markdown app, and at the non-standard extras (wiki links, callouts, YAML front matter) that stay behind when the file moves.
- Why did half my formatting silently do nothing? Markdown in Discord maps the small supported subset, spoiler tags and code block languages, so you stop typing syntax that is never read.
- Should I be in the fancy editor or Markdown mode? Markdown in Reddit settles that one, along with the quirks of Reddit's own parser.
If the question is the dialect, not the app
Sometimes you are not choosing a platform at all, only deciding what to write for. In that case which Markdown flavor should you write for answers it directly, and the GitHub Flavored Markdown guide documents the extended set these platforms converged on. For the elements themselves, start at the Markdown syntax hub.
Watch out: Do not test portability with a short paragraph. Nearly everything survives that. Move a real document with a table, a nested list and a footnote in it, because those three break first.
Support data verified
Frequently Asked Questions
Which apps support Markdown?
Most developer and writing tools do: GitHub, GitLab, Obsidian, VS Code, Jupyter, Ghost and every static site generator. Chat apps support a subset: Discord and Slack handle emphasis and code but not tables.
Does Notion support Markdown?
Partly. Notion accepts Markdown as input, so typing ## creates a heading, and it imports and exports .md files. It never stores Markdown: the symbols become blocks and are discarded. See Markdown in Notion for which shortcuts work.
Why does my table work on GitHub but not in Discord or Slack?
Because tables are extended syntax, not core Markdown. GitHub implements the GitHub Flavored Markdown extension set; Discord and Slack deliberately implement a small subset aimed at short messages. The parser on the other end simply has no rule for it.
Can I move my notes from Notion to Obsidian?
Yes, via Notion's Markdown export, but expect cleanup. Headings, lists, emphasis, code and links come across well; databases, toggles, callouts and embeds have no plain Markdown equivalent. Moving the other way is easier, which is the argument for drafting in a tool that stores .md.
Is there one version of Markdown that works everywhere?
Yes, and it is smaller than you would like: headings, bold, italic, lists, links, images, inline code, code fences and blockquotes. Everything else depends on the platform. That subset is the reliable way to keep a document portable.
Keep learning
Try the Editor
Try the Editor