Markdown formatter

What gets normalized

• List markers — a document mixing -, *, and + bullets comes out using one marker of your choice, with consistent indentation for nested lists.
• Emphasis style — *asterisks* and _underscores_ render identically, but mixing them in one file reads badly. Pick one; the formatter applies it everywhere, to bold too.
• Tables — cells get padded so pipes line up vertically, the same formatting our table generator produces.
• Headings — setext headings (underlined with ===) become ATX headings (#), and stray spaces after the hashes are removed.
• Spacing — extra blank lines collapse, and blocks are separated by exactly one blank line, which some renderers require.

Semantic formatting, not find-and-replace

The formatter is built on remark, the same parser used by Prettier's markdown support and thousands of documentation pipelines. Your text is parsed into a syntax tree and printed back out — which is why it can safely tell the difference between a * that starts a list item and a * inside a sentence, or between an underscore in variable_name and one that starts emphasis. A regex-based beautifier can't make those distinctions; a parser can.

One consequence worth knowing: because the output is re-printed from the tree, insignificant quirks of your original source (trailing whitespace, inconsistent escape styles, indented vs. fenced code) are normalized to the standard form. If some exotic construct matters to your toolchain, diff the output before committing it.

When to use it

• Before committing docs — a formatted README diffs cleanly in code review because only real changes show up, not style noise.
• After AI generation — LLM-generated markdown often mixes emphasis markers and bullet styles mid-document; one pass here fixes it.
• Merging docs from multiple authors — unify everyone's habits into one house style.
• Cleaning up exports — Notion, Google Docs, and other exporters produce technically-valid but ugly markdown.

FAQ