search

Found

info Overview

Turn your Markdown headings into a paste-ready table of contents. Set H2-H6 depth, bullets or numbering, and GitHub anchors; fenced code # is skipped.

📘 How to Use

  1. Paste your Markdown into the input field
  2. Choose heading depth, list style, and anchor format
  3. Review the generated TOC in the output field

Markdown TOC Generator

0 headings
Copied
Article

Markdown Table of Contents Generator | Paste-Ready TOC From Your Headings

Drop a Markdown document in and get back a table of contents you can paste straight at the top of your README or article. Pick the heading depth, bullet or numbered style, and GitHub anchors, and the formatted Markdown appears in the output pane.

💡 About This Tool

If you maintain a long README or write deep documentation, you already know the chore: every time you reorganize a section, the hand-written TOC drifts out of sync. A renamed heading breaks its anchor link, a new ## never makes it into the list, and reviewers waste a round catching it.

This tool rebuilds the TOC from the headings themselves, so the structure always matches the body. Nesting is rendered with two-space indentation relative to the shallowest heading found, which means a doc that starts at ## indents cleanly without a leading empty level. GitHub anchors follow GitHub's own slug rules — lowercase, spaces to hyphens, and anything outside a-z, 0-9, hyphen, or underscore stripped — so the links resolve on github.com without manual tweaking.

🧐 Frequently Asked Questions

Does it include the H1? You choose the depth from H2 through H6. Keeping your page title as the single H1 and starting the TOC at H2 gives you a clean outline of the body without the title line repeated.

Will the GitHub anchors actually work on GitHub? They match GitHub's heading-slug algorithm, so for ASCII headings they resolve directly. Emoji and most punctuation get stripped, matching GitHub's behavior. If a heading slugifies to something empty (rare with English text), switch the anchor style to None for a plain text list.

Does it confuse # comments inside code blocks? No. Anything inside a fenced code block opened with ``` or ~~~ is skipped until the matching closing fence, so shell prompts and Python comments never get mistaken for headings.

How are numbered lists numbered? Every item is emitted as 1.. Markdown renderers auto-increment ordered lists, so leaving them all as 1. in the source is the idiomatic, diff-friendly choice.

What controls the indentation depth? The shallowest heading level present becomes the baseline, and everything else indents relative to it. Whether your doc starts at H1, H2, or H3, the visual hierarchy stays intact.

📚 Why a Generated TOC Beats a Hand-Written One

On big open-source repos, a stale table of contents is one of the most common documentation papercuts: contributors add sections in a pull request and forget the TOC, so the anchor links 404 for the next reader. Regenerating the TOC from headings makes the list a derived artifact rather than a thing you maintain by hand. It also keeps anchors honest — because the slug is computed the same way GitHub computes it, you avoid the classic mismatch where a heading reads "Set-Up" but the hand-typed anchor said #setup. Treat the output as something you regenerate whenever the outline changes, not something you patch.