Markdown Formatter Online — Format Markdown

Normalise ATX headings, list bullets, blank-line spacing, GFM tables, and fenced code blocks for CommonMark and GitHub Flavored Markdown — 100% in your browser.

Input Markdown

Formatted Output

What is a Markdown Formatter?

A Markdown formatter normalises Markdown documents — fixing inconsistent ATX heading spacing, standardising list bullets, collapsing runs of blank lines, ensuring fenced code blocks have surrounding blank lines, and aligning GFM tables. It is the same convention applied by Prettier with the markdown plugin and markdownlint with default rules.

Markdown is whitespace-tolerant: # Heading and # Heading render identically, three blank lines collapse to one, and inconsistent indentation in lists is forgiven. But the source diff is noisy, and contributors with different editors produce conflicting whitespace. A formatter removes that noise so reviews focus on content, not whitespace.

How to format Markdown — 4 steps

Paste your Markdown. Copy a README, documentation page, or any Markdown source into the Input panel. Click Load Sample to try a demo.
Click Format. The formatter normalises headings, lists, blank lines, and code fences client-side.
Review the output. The Output panel shows the normalised Markdown ready for commit or publish.
Copy the result. Click Copy to paste the formatted Markdown into your editor or PR.

Side-by-side: messy vs normalised Markdown

Messy

#  Title
##Subheading
*    Item one
*    Item two



More text.

Normalised

# Title

## Subheading

* Item one
* Item two

More text.

CommonMark + GFM

Normalises ATX headings, list bullets, blank lines, code fences, and GFM tables to canonical form.

Render Identical

Markdown is whitespace-tolerant. Normalised source renders byte-identical HTML in every CommonMark parser.

Client-Side Only

Documentation with internal API names, draft content, or unreleased feature notes never leaves your browser.

Common use cases

check_circleFormat a project README before committing to GitHub or GitLab
check_circleNormalise documentation contributed by multiple authors with different editor settings
check_circleReformat Markdown exported from Notion, Obsidian, or Bear
check_circleClean up Markdown generated by an AI assistant before publishing
check_circleFormat API documentation in a docs-as-code workflow before a docs deploy
check_circleNormalise list and heading style in a wiki page
check_circleReformat Markdown after a merge conflict resolution
check_circleClean up release notes before tagging a version

Online formatter vs Prettier vs markdownlint

An online formatter is the fastest tool for one-off documents — paste, click, copy. Prettier with --parser markdown is the right tool for project-wide enforcement: configure .prettierrc and a pre-commit hook so every .md file is formatted on save. markdownlint goes further — it lints for style rules (heading hierarchy, line length, alt text on images, link reference consistency) on top of formatting. Use this online tool for quick fixes; use Prettier + markdownlint together in CI.

More than formatting

Format HTML, JSON, or convert between data formats — all browser-side.

HTML Formatter JSON Formatter GraphQL Formatter

Frequently Asked Questions

What is the difference between ATX and Setext headings?

ATX headings use # prefix (# H1, ## H2, up to ###### H6) and are the modern convention used by GitHub, GitLab, and most static site generators. Setext headings use underlines (=== for H1, --- for H2) but only support two levels and require knowing the line above. Prettier and most markdownlint configs prefer ATX. The formatter normalises everything to ATX.

Should I use - or * for bullet lists?

Both are valid CommonMark. The dominant convention in 2026 is - (hyphen) — used by Prettier, the GitHub style guide, and most open-source READMEs. * (asterisk) is also common, especially in older Markdown. + (plus) is rare. Pick one style and stay consistent within a document; the formatter does not change your bullet character but fixes spacing after it.

How are blank lines between blocks normalised?

Markdown requires exactly one blank line between block elements (paragraphs, lists, headings, code blocks). Multiple consecutive blank lines render as a single blank in every CommonMark parser, but they bloat the source and create noisy diffs. The formatter collapses 3+ blank lines to exactly one — a Prettier and markdownlint convention.

How are tables formatted?

GitHub Flavored Markdown tables use pipes and a separator row (| --- |). Prettier and most formatters align column widths so each cell pads to the longest entry, and the separator row matches the column count. Alignment markers (:---, :---:, ---:) for left/center/right alignment are preserved. The formatter ensures one space inside each pipe.

Are fenced code blocks preserved exactly?

Yes. The interior of a fenced code block (between ``` and ```) is preserved byte-for-byte — that is essential because code samples cannot tolerate reformatting. The formatter only ensures a blank line before and after the fence, and that the language tag stays on the opening fence (```javascript not ``` javascript).

Does formatting Markdown change how it renders?

No. CommonMark and GFM are whitespace-tolerant: extra spaces after # in a heading, multiple blank lines, and inconsistent list spacing all render identically. Formatting only normalises the source so diffs are clean and the file is easier to maintain. The rendered HTML is byte-identical.

Does it handle MDX (Markdown with JSX)?

Partially. The formatter normalises Markdown-level constructs (headings, lists, tables, code fences) inside MDX files. JSX components (<MyComponent />, ESM imports) are left as-is — formatting JSX requires a JS parser. For full MDX formatting, use Prettier with the MDX plugin.

Is the Markdown I paste sent to your servers?

No. Formatting runs entirely in your browser using JavaScript. Documentation containing internal API names, draft content, or unreleased feature notes never leaves your device. Open DevTools → Network and click Format to verify.