You already know Markdown.

You use it every day — in README files, GitHub issues, pull requests, documentation, and blog posts. It's everywhere in the developer world.

But here's the thing: most developers write functional Markdown. It renders. It works. But it's not always clean, consistent, or easy for teammates to read in its raw form.

And raw readability matters more than people realise. Your teammates read it in code review. Your future self reads it six months later. CI tools parse it. Inconsistent formatting causes real problems — broken renders, messy diffs, and documentation that slowly becomes a mess to maintain.

This guide covers the Markdown practices that actually make a difference. Not just the basics — but the specific habits that separate good documentation from great documentation.

Let's get into it.

Why Markdown formatting standards matter

Before diving in, let me explain why this is worth caring about.

Markdown has no single universal specification that all tools agree on. GitHub uses GitHub Flavored Markdown (GFM). VS Code defaults to CommonMark. dev.to has its own rendering quirks. Notion handles things differently again.

The same .md file can render differently depending on where you open it.

The best defence against this? Write clean, consistent, unambiguous Markdown. Follow the conventions. Use tools to enforce them.

It's the same reason we use Prettier for JavaScript. You stop thinking about formatting and just write — the tooling handles the rest.

1. Use ATX-style headings (with a space after #)

There are two heading styles in Markdown. ATX uses # symbols. Setext uses underlines (=== or ---).

Always use ATX. It's cleaner, more readable, and supported everywhere.

<!-- ✅ Do this -->
## My Section Heading

<!-- ❌ Not this -->
My Section Heading
------------------

Also — always put a space between the # and your heading text. Some parsers require it. Others don't. But the space is specified in the CommonMark spec, so it's the safest habit.

<!-- ✅ Correct -->
## Introduction

<!-- ❌ Risky -->
##Introduction

One more rule: never skip heading levels. Go H1 → H2 → H3 in sequence. Jumping from H1 directly to H4 breaks screen readers and makes your document structure confusing to navigate.

2. Always specify a language in fenced code blocks

Whenever you write a fenced code block, add a language identifier.

<!-- ✅ Do this -->

javascript
const greet = (name) => Hello, ${name}!;

<!-- ❌ Not this -->

javascript
const greet = (name) => Hello, ${name}!;

markdown

Why does it matter?

• Syntax highlighting activates
• Readers immediately know what they're looking at
• Documentation generators use it for formatting and indexing
• Screen readers can announce the language type

Common language identifiers: javascript, typescript, python, bash, json, yaml, sql, css, html, go, rust.

Use lowercase by convention. javascript is standard. JavaScript works in most parsers, but it's not consistent.

3. Keep list markers consistent

Unordered lists accept -, *, or + as markers. Pick one and use it throughout the entire document.

The most widely recommended choice is -.

<!-- ✅ Consistent — do this -->
- First item
- Second item
- Third item

<!-- ❌ Inconsistent — avoid this -->
- First item
* Second item
+ Third item

Mixing markers isn't just visually messy. Some parsers treat different markers as separate lists entirely, which breaks the rendered output.

For ordered lists, use 1. for every item rather than incrementing manually. If you insert or reorder items later, the numbering stays correct automatically.

<!-- ✅ Easier to reorder -->
1. Install dependencies
1. Configure the environment
1. Start the server

<!-- Rendered output is still: 1, 2, 3 -->

4. Add blank lines around block elements

This is one of the most common mistakes in Markdown files. Block elements — headings, code blocks, lists, blockquotes — need blank lines before and after them.

Without blank lines, some parsers get confused and produce unexpected output.

<!-- ❌ Missing blank lines — risky -->
Here's some intro text.
## Section Heading
More text here.
- Item one
- Item two
Some conclusion.

<!-- ✅ Properly spaced -->
Here's some intro text.

## Section Heading

More text here.

- Item one
- Item two

Some conclusion.

The raw file becomes far more readable too. When someone scans a .md file in a terminal or basic text editor, the spacing makes the structure obvious at a glance.

5. Write descriptive link text — not "click here"

This is a writing best practice as much as a Markdown one. But it shows up constantly in developer docs.

<!-- ❌ Tells the reader nothing -->
For more information, [click here](https://example.com/docs).

<!-- ✅ Tells the reader exactly where they're going -->
See the [official API documentation](https://example.com/docs) for details.

Descriptive link text matters for three reasons:

1. Accessibility — screen readers announce link text out of context. "Click here" is meaningless when read aloud in a list of links.
2. SEO — anchor text signals to search engines what the linked page is about.
3. Scannability — readers can understand the link's destination without stopping to click it.

Make your link text describe the destination, not the action.

6. Wrap technical terms in inline code

Any time you mention a function name, variable, file path, command, or technical term in prose — wrap it in backticks.

<!-- ❌ Technical terms blend into the text -->
Run npm install in the root directory, then open the config.js file.

<!-- ✅ Technical terms stand out immediately -->
Run `npm install` in the root directory, then open `config.js`.

This is one of those small habits that has a big impact on readability. Technical terms pop out visually. Readers can immediately tell "this is something I need to type or pay attention to" versus surrounding explanation.

7. Use blockquotes for the right things

Blockquotes are for quoting external content, adding important notes, or creating callouts. They're not for indentation or visual decoration.

<!-- ✅ Good use — an actual callout -->
> **Note:** This configuration only applies to production environments.

<!-- ❌ Misuse — this is just prose, not a quote -->
> This section explains how to set up your project.

On GitHub, you can use the alert syntax for proper callout blocks. It's more semantic and renders with distinct styling:

> [!NOTE]
> Highlights information the reader should take into account when skimming.

> [!WARNING]
> Critical content that demands immediate attention.

> [!TIP]
> Optional information to help the reader be more successful.

These render as styled, colour-coded callout boxes on GitHub — much cleaner than the old bold-in-a-blockquote approach. Use them in README files and documentation pages.

8. Align table pipes for raw readability

Markdown tables are notoriously awkward to write by hand. The pipes rarely line up, and the raw file becomes painful to read.

<!-- ❌ Valid, but hard to read in raw form -->
|Name|Role|Status|
|--|--|--|
|Alice|Developer|Active|
|Bob|Designer|Active|

<!-- ✅ Clean and readable even before rendering -->
| Name  | Role      | Status |
|-------|-----------|--------|
| Alice | Developer | Active |
| Bob   | Designer  | Active |

Both render identically. But the second version is readable in a code review, a terminal, or a plain text editor — places where your Markdown lives before it gets rendered.

Aligning pipes manually every time is tedious. A Markdown formatter does it instantly — paste your document in, get back clean, consistently formatted Markdown with aligned tables, proper spacing, and normalised list markers.

9. Use reference-style links for long URLs

When URLs are long, inline links clutter the prose and make it hard to read.

<!-- ❌ The URL overwhelms the sentence -->
See the [deployment guide](https://docs.example.com/guides/production/deployment/advanced-configuration?tab=docker&version=v3) before going live.

<!-- ✅ The prose stays clean -->
See the [deployment guide][deploy] before going live.

[deploy]: https://docs.example.com/guides/production/deployment/advanced-configuration?tab=docker&version=v3

Reference-style links work like footnotes. The prose reads naturally, and all the URLs sit at the bottom of the file where they're easy to update without touching the text.

This pays off especially in long documentation files where the same link appears multiple times.

10. End files with a single newline

This one's subtle but matters for git hygiene.

Every text file — including .md files — should end with exactly one newline character. Most editors do this automatically, but not all.

Without a trailing newline:

• Git shows a \ No newline at end of file warning in diffs
• Diffs become noisy in pull requests
• Some POSIX tools behave unexpectedly when reading the file

In VS Code, enable this automatically with "files.insertFinalNewline": true in your settings. Most other editors have an equivalent option.

Tools that enforce all of this automatically

Reading these practices is useful. Remembering every single one while you're writing — less so.

The practical move is to integrate enforcement into your workflow so you don't have to think about it.

For teams and CI pipelines:

• markdownlint — the most widely used Markdown linter. Available as a CLI, a VS Code extension, and a GitHub Action. Enforces rules like heading hierarchy, code block languages, and list consistency. Configurable with a .markdownlint.json file.
• Prettier — if your team already runs Prettier on code, it handles Markdown too. Good for enforcing consistent prose wrapping and spacing.
• remark — a powerful Markdown processor with a rich plugin ecosystem. Useful when you need to both lint and programmatically transform Markdown files.

For individual workflow:

The fastest option is to run your Markdown through a formatter before you commit or publish. It catches the things you'd otherwise miss — a missed blank line, an unspecified code block language, misaligned table pipes — without requiring any setup.

Quick reference

Final thoughts

Markdown is deceptively simple. The basics take minutes to learn. But clean, consistent Markdown — readable in both raw and rendered form — takes deliberate habits.

The good news: most of this can be automated. Add markdownlint to your editor. Set up a GitHub Action to check Markdown on every pull request. Run docs through a formatter before you publish.

Set the standard once. Enforce it automatically. Then spend your energy on writing content worth reading.

What Markdown practices has your team standardised on? Drop a comment — I'd love to know what's working.