Markdown Formatter

A Markdown formatter cleans up the whitespace and structure of Markdown so it’s easier to read and maintain. This tool focuses on a few high-value fixes:

• normalizing heading spacing (e.g., #Title → # Title)
• trimming trailing whitespace
• standardizing list markers (e.g., -item → - item)
• reducing excessive blank lines

It’s meant for quick cleanup of pasted notes, README drafts, and documentation snippets — not for enforcing every rule of every Markdown dialect.

1. Paste your Markdown: Add a README section, docs snippet, or notes.
2. Choose cleanup options: Heading spacing, trailing whitespace trimming, and list normalization.
3. Copy the formatted Markdown: Paste back into your editor or repo.

• Cleaner diffs: Consistent whitespace reduces noisy pull requests.
• More readable docs: Proper spacing around headings and lists improves scanning.
• Less accidental breakage: Normalized lists/headings render more predictably.

Use case 1: README polishing

Format headings and lists before committing so the README looks clean and review diffs stay focused on content changes.

Use case 2: Converting notes into documentation

Pasted notes often have inconsistent spacing and list syntax. Formatting helps turn them into publishable docs quickly.

Use case 3: Preparing Markdown for conversion

If you’re going to convert Markdown to HTML or another format, formatting first can reduce conversion surprises.

This is a pragmatic “cleanup” formatter. It focuses on a few fixes that make Markdown more consistent in most renderers:

• Adds a missing space after heading markers (#Title → # Title)
• Ensures headings have sensible blank lines around them
• Normalizes list markers (-item → - item, 1.Item → 1. Item)
• Trims trailing whitespace
• Collapses excessive blank lines (keeps a maximum of two)

It does not attempt to reflow paragraphs, rewrite prose, or enforce every rule of every Markdown dialect. Think of it as a fast way to make pasted Markdown easier to read and diff.

Normalize heading spacing

This option fixes missing spaces after # and adds blank lines around headings. It’s great for READMEs and docs, but it can affect lines inside code fences if those lines look like headings.

Trim trailing whitespace

Trailing spaces can create noisy diffs and sometimes cause subtle rendering issues. Trimming them is usually safe and is a good default for repositories.

Normalize list formatting

This adds a space after list markers:

• -item → - item
• 1.Item → 1. Item

It’s helpful for consistent rendering, but if you have code examples that start with - at the beginning of a line, review the output.

If you’re maintaining documentation in a repo, a simple routine keeps diffs clean:

1. Write or paste your Markdown.
2. Run it through this formatter.
3. Convert/preview (for example using Markdown to HTML) if you’re unsure how it will render.
4. Commit the cleaned version.

This reduces “whitespace-only” noise in reviews and makes it easier to spot real content changes.

Basic example (fix heading spacing)

Input: #Header with no space
Output: # Header with no space

Advanced example (headings + lists + blank lines)

Input:

#Title
- item1
-item2

##Subhead
Text

Output:

# Title

- item1
- item2

## Subhead

Text

“It changed things inside my code block”

This is a lightweight formatter — it doesn’t fully parse Markdown and may apply spacing rules broadly. If you have complex Markdown (especially with code fences that look like headings or lists), review the output or use a fully Markdown-aware formatter like Prettier in your editor.

My code fence content got modified

If a fenced code block contains lines that start with #, -, *, or 1., they can resemble headings/lists and may get normalized. Two safer approaches:

• Temporarily turn off heading/list normalization, format, then re-enable.
• Use a Markdown-aware formatter in your editor for documents with heavy embedded code.

My Markdown flavor has special rules

Different renderers support different features (tables, task lists, etc.). This tool aims for safe, general cleanup. If you need strict renderer compatibility, test in the target environment.

I expected it to rewrite my sentences

This tool formats structure and whitespace — it doesn’t change your wording. For text editing, use tools like Remove Line Breaks or Plain Text Converter.

If the output isn’t what you expected:

1. Check code fences: if you have lots of fenced code, review the formatted result carefully.
2. Toggle options: heading/list normalization are the most likely to change code-like lines.
3. Preview the render: copy the result into your target renderer (GitHub, Notion, your docs site) before publishing.
4. Use a strict formatter when needed: if your repo uses Prettier/remark, run that as the final pass for canonical formatting.

• Format before committing to keep diffs readable.
• If you’re converting to HTML, format first and then use Markdown to HTML.
• For tables, make sure your renderer supports GFM tables; see GitHub Flavored Markdown for reference.
• If you want to remove pasted rich-text styling before formatting, run the text through Plain Text Converter first.
• For long docs, format after major edits so headings and lists stay consistent across sections.
• If a document contains lots of fenced code blocks, format in smaller chunks so you can quickly spot any unwanted changes.

• Convert content with Markdown to HTML and HTML to Markdown.
• Turn tabular data into Markdown using the Markdown Table Creator.
• Clean JSON snippets inside docs with the JSON Formatter.

Formatting runs locally in your browser. Nothing you paste is uploaded or stored. No account is required.