If you searched for "markdown heading", "markdown headers", "markdown h1", or "markdown heading sizes", you likely need a fast reference and a practical formatting model.
This guide explains heading syntax, hierarchy strategy, and common mistakes for production docs.
Quick answer: how do markdown heading sizes work?
Markdown headings are defined by leading symbols.
creates H1creates H2creates H3creates H4creates H5creates H6
More means lower heading level.
Markdown heading syntax table
| Markdown | Rendered HTML | Typical use |
|---|---|---|
| | page title |
| | primary section |
| | nested section |
| | optional deep nesting |
| | rare support heading |
| | rare technical label |
Example:
Recommended heading hierarchy
Use headings as an outline, not visual decoration.
Good hierarchy:
- one H1 per page
- H2s for major sections
- H3s for scoped details under H2
- avoid jumping from H2 directly to H5
This improves:
- reader navigation
- table-of-contents generation
- accessibility for assistive technology
Common markdown heading mistakes
1. Multiple H1 titles on one page
Use one H1 as the canonical page title.
2. Using headings for visual size only
If text should look larger but not introduce a new section, use styles, not deeper heading levels.
3. Missing space after hashes
Correct:
Incorrect:
4. Skipping heading levels without structure
Avoid abrupt jumps unless there is clear structural reason.
Markdown heading examples by use case
README structure
Tutorial structure
API documentation structure
Heading IDs and linkable anchors
Many markdown renderers auto-generate heading IDs.
Example:
Often becomes anchor:
Use stable, descriptive heading text to avoid brittle links.
Markdown headings and SEO snippets
Heading quality affects how content is interpreted by crawlers and users.
Strong heading patterns:
- explicit problem statement (
) - answer-style sections (
) - stepwise labels (
,)
For technical content, this often improves snippet eligibility and scannability.
Testing markdown output before publishing
Before shipping markdown-heavy pages:
- Render in your target platform (GitHub, docs site, CMS)
- Check heading levels in preview
- Verify TOC or anchor links
- Confirm no duplicate section names where possible
- Validate code block formatting
If your docs include email workflows, you can pair markdown docs with real send-receive tests using MailSlurp testing tools.
FAQ
Is markdown heading size configurable?
Semantically, heading level is fixed by count. Visual size can be changed by CSS in your renderer.
Can markdown have multiple H1 headings?
Technically yes, but one H1 per page is the best default for structure and SEO clarity.
Does heading level affect GitHub rendering?
Yes. GitHub renders H1-H6 according to heading level and uses headings for navigation/anchors.
Should I use H4-H6 often?
Usually no. Most docs remain clear with H1-H3.
Final take
Markdown headings are simple syntax with high leverage. A clean hierarchy makes your docs easier to read, easier to maintain, and easier to rank.
Convert heading quality into release quality
Good markdown structure reduces ambiguity. Ambiguity is where broken flows usually start.
Use this handoff model when your docs describe email or notification behavior:
| Docs signal | Engineering action | Validation route |
|---|---|---|
| Clear H2/H3 sequence for an integration flow | Encode each step as an executable test stage | Email Integration Testing |
| Explicit failure and retry sections | Mirror the same retry policy in routing logic | Email Automation Routing |
| Concrete webhook payload examples | Validate payload format and async behavior against real events | Email Webhooks |
| Claims about “delivered” or “working” | Verify final message outcomes before release | Email Deliverability Test |
If your docs include send/receive examples, run them against Email Sandbox and keep implementation references aligned with your Email API path. That keeps docs trustworthy and makes onboarding faster for new engineers.




