Markdown Preview: See Rendered Markdown as You Type

A markdown preview shows the rendered result of your .md file, headings, tables, and all, while you keep typing symbols in the source. Every serious tool has one, and they disagree with each other. This guide explains what a renderer is, where the preview lives in each tool, and why the same file looks different in two of them.

What Is a Markdown Renderer?

A markdown renderer is three things stacked together. A parser reads your text and builds a tree of blocks. An HTML generator turns that tree into tags. A stylesheet decides what those tags look like. "Render markdown" means running all three.

Markdown rendering and previewing are the same operation; a preview just runs it continuously as you type. People also call it an md preview, a live preview, or simply rendering Markdown, and every term means the same three steps.

Every layer can differ between tools. The parser decides whether - [ ] is a checkbox or four characters. The HTML step decides whether a footnote becomes a link. The CSS decides whether headings are blue. So when a colleague says "it looks fine in my preview," they're telling you about their parser, not yours.

The parsers fall into families. CommonMark is the base spec. GitHub Flavored Markdown adds tables, task lists, strikethrough, and autolinks on top, and GitHub itself layers footnotes, alerts, math, and Mermaid above that. Obsidian, Pandoc, and MultiMarkdown each add their own extensions. A markdown live preview is only "correct" relative to one of these dialects.

The Dialect Test Snippet

Paste this into any preview and you'll know its dialect in ten seconds.

| Feature | Renders? |
|---|---|
| Table | ? |

- [ ] task list item
- [x] done item

A footnote reference.[^1]

> [!NOTE]
> A GitHub-style alert.

Inline math: $E = mc^2$

A [[wikilink]] to another note.

[^1]: The footnote text.

Here's what happens to it in the tools covered below. Cells marked "tested" reflect our own checks; the rest come from each tool's documentation.

Element	GitHub	Our editor (tested)	VS Code built-in	Obsidian
Table	Yes	Yes	Yes	Yes
Task list	Checkbox	Checkbox	Literal text	Checkbox
Footnote	Yes	Literal text	Needs an extension	Yes
> [!NOTE] alert	Styled box	Plain quote	Plain quote	Styled callout
$E = mc^2$	Yes	Yes (KaTeX)	Yes	Yes
[[wikilink]]	Literal	Literal	Literal	Link

How Do You Preview Markdown Online?

An online markdown preview needs nothing installed and works on a locked-down machine, a Chromebook, or a phone. If you searched for markdown preview online or render markdown online, this is the option you wanted.

In our editor the left pane is the source and the right pane re-renders on every keystroke. It renders GFM tables, task lists, strikethrough, fenced code, Mermaid diagrams, and KaTeX math. It doesn't render footnotes, GitHub alerts, or wikilinks, which puts it close to a GitHub comment box rather than a full README page.

The snippet is loaded below. Change a cell, tick a box, break the table, and watch the right side.

When you need the exact HTML rather than a picture of it, the Markdown to HTML converter gives you the markup to inspect or paste into a page. For a preview of local files in a browser tab, a Markdown viewer extension for Chrome is the lighter option.

Markdown Preview on GitHub

GitHub renders every .md file in a repository automatically, and the web editor has a Preview tab next to Edit for any file whose name ends in .md. The GFM spec defines the base, and GitHub's own docs add footnotes, > [!NOTE] alerts, $ math, and Mermaid fences on top.

Two things people miss. Issue and pull request comments render nearly the same dialect as files, but wikis don't support footnotes. And the README on a repository home page is rendered with the same engine as the Preview tab, so what you see in the tab is what visitors get. For the ways to check GitHub's exact output before you push, see our guide to previewing GitHub Markdown.

Obsidian: Live Preview and Reading View

Obsidian has three views. Source mode shows raw Markdown. Live Preview renders formatting inline while you type, hiding most symbols until your cursor lands on them. Reading view is a pure rendered page. Ctrl+E (Cmd+E on a Mac) toggles between editing and reading. The status bar icon or the command palette switches Live Preview and Source mode, as Obsidian's Edit and read help page describes.

Obsidian's dialect is the widest of the four. Wikilinks, embeds, callouts with > [!note], footnotes, math, and Mermaid all render. The trade-off is portability: a note full of [[links]] and callouts looks broken in every other preview. Our Obsidian Markdown cheat sheet lists which syntax is Obsidian-only.

Markdown Preview in VS Code

Press Ctrl+Shift+V (Cmd+Shift+V) to open the preview, or Ctrl+K then V to dock it beside the editor with scroll sync. The VS Code docs state that the preview uses markdown-it and targets CommonMark, with tables and strikethrough, math, and Mermaid diagrams built in. Footnotes and task-list checkboxes need an extension; Markdown Preview Enhanced adds those plus PlantUML, code chunks, and PDF export.

The preview also has a security setting, Strict by default, that blocks http:// images and scripts. That setting is the usual reason "my images don't show." Extensions, linting, and settings are covered in the VS Code Markdown guide.

Previewing in Neovim and the Terminal

Neovim doesn't render anything by itself. The standard answer is markdown-preview.nvim, which opens a browser tab that follows your cursor. With lazy.nvim:

{
  "iamcco/markdown-preview.nvim",
  cmd = { "MarkdownPreviewToggle", "MarkdownPreview", "MarkdownPreviewStop" },
  ft = { "markdown" },
  build = function() vim.fn["mkdp#util#install"]() end,
}

Then :MarkdownPreview starts it and :MarkdownPreviewStop ends it. The plugin's README lists synchronised scrolling, KaTeX, Mermaid, PlantUML, and task lists, and it requires Node.js. Our Neovim Markdown post compares it with in-buffer rendering.

For a preview that never leaves the terminal, glow renders a file with colours and layout: brew install glow, then glow README.md, or glow -p to page through it. It handles headings, lists, tables, and code, but a terminal can't show images or clickable checkboxes, so treat it as a reading tool rather than a fidelity check. The terminal Markdown viewer guide covers glow's flags and alternatives.

Why Does My Markdown Preview Look Different from GitHub?

Because the two tools run different parsers, and sometimes different CSS on the same HTML. Work through these in order.

Dialect. Paste the test snippet above into both. If checkboxes, footnotes, or alerts differ, that's the parser, and no setting will change it. Write to the narrower dialect if the file has to render in both.

Blank lines. Many parsers want a blank line before a table or an ordered list that follows a paragraph. GitHub is forgiving about this; stricter parsers are not.

Line breaks. Some previews, ours included, turn a single newline into a line break the way GitHub comments do; README files on GitHub and most static site generators join the lines instead.

Images. A relative path that works in a repository fails in a browser preview of a single file, and VS Code's strict mode blocks http:// sources.

Styling. Two previews can produce identical HTML and still look different because one loads GitHub-style CSS and the other doesn't. That's cosmetic; the structure is right.

Our preference: draft in one preview, then check the file where it will actually live before you call it done. One limitation of every preview is that it can't tell you which renderer your reader will use.

Markdown Preview FAQ

A markdown preview is only as trustworthy as the renderer behind it, so learn the dialect of the place your file will live and preview there when it matters. For everything before that point, the fastest loop is the editor: paste, look, fix, repeat, then export or download the file when the right side looks the way you want.