Markdown TOC Generator
Generate a Markdown table of contents from any heading structure — GitHub / GitLab / plain anchor styles, configurable depth.
Pourquoi utiliser cet outil
05Free in-browser Markdown TOC generator. Paste any Markdown document and get a nested table of contents with proper anchor links. Pick the anchor style for your destination (GitHub, GitLab, or plain-text slugs), cap the depth at H2-H6, and optionally skip the document title (H1). Runs locally.
Paste a Markdown document and the tool extracts every #-style heading, generates an anchor slug for each, and emits a nested Markdown list with one entry per heading — properly indented by depth so it renders as a tree.
The anchor style toggle matters: GitHub's slugify rules differ slightly from generic Markdown processors. Pick the destination platform so the generated [Title](#slug) links actually navigate when rendered there.
Other settings: cap depth at H2/H3/H4/H5/H6 (deeper headings are skipped), and optionally exclude the document's H1 title (most READMEs use H1 as the document title and don't want it in the TOC).
Especially useful for README files, technical blog posts, design docs, and internal documentation. Pair with our Markdown Live Preview to see the rendered output, or with Slug Generator if you need to slug a custom title separately.
Comment l'utiliser
03Vérifications rapides avant de copier
03Confirmez que le format de saisie est celui attendu.
Vérifiez le résultat avant de l'utiliser dans un document, une URL, une config ou un message.
Copiez uniquement le résultat dont vous avez besoin.
Cas d'utilisation
READMEs over a few screens benefit from a top-of-file TOC. Paste your full README in, copy the output, and paste it after the intro. Use the GitHub anchor style if the README lives on GitHub.
Many static-site generators (Docusaurus, Nextra, MkDocs) consume Markdown with anchor links. Use this tool to pre-generate the TOC instead of relying on the framework's auto-TOC plugin if you want manual control.
Long internal design docs benefit from a navigable TOC. The depth cap means you can show top-level sections only (H2) or include sub-sections for fine-grained navigation.
GitHub, GitLab, and other Markdown renderers have slightly different slugify rules. When porting docs between systems, regenerate the TOC with the matching anchor style so links don't break.
Generating the TOC is a fast way to see if your headings flow logically. A TOC with too-deep nesting, repeated section names, or missing H2-level sections usually signals an organization problem worth fixing.
Conseils et astuces
- 01Duplicate headings auto-deduplicate the slug
If you have two sections with the same title (e.g., "Examples"), the second one gets <code>-1</code> appended to its slug to keep links unique. This matches GitHub and most other Markdown processors' behavior.
- 02Code blocks are ignored
Lines that look like headings inside <code>```</code>-fenced code blocks (e.g., a shell prompt that includes a hash) are correctly excluded from the TOC.
- 03Indent reflects relative depth, not absolute
If your document starts at H2 (no H1, or H1 skipped), H2 sits flush-left in the output. The TOC tree's root is whichever level is shallowest in your filtered headings.
- 04Plain slug style strips non-ASCII characters
GitHub's slugify keeps Unicode letters (so a Chinese or Korean heading produces a usable slug). The plain style strips everything outside ASCII for maximum compatibility with older Markdown renderers.
FAQ
07
Does the tool run entirely in my browser?
Yes. Parsing and slug generation are pure JavaScript with no network calls. Safe for proprietary documents — nothing is uploaded.
What anchor styles are supported?
Three: GitHub (default — lowercase, Unicode-preserving, spaces to hyphens, strips most punctuation), GitLab (almost identical to GitHub for typical headings), and Plain (ASCII-only, strict). Pick the one that matches where your Markdown will render.
Why is my generated TOC link broken on GitHub?
Most common causes: (1) the heading text contains characters not in the slug alphabet (emoji, certain Unicode symbols), (2) the document was rendered before the heading was added so GitHub's slug cache is stale (try editing the file), or (3) a slug collision exists higher up the document so this heading's slug got a <code>-1</code> suffix you weren't expecting.
Does it support setext headings (<code>===</code> / <code>---</code>)?
Not currently — only ATX-style <code>#</code>-prefixed headings are recognized. If your document uses setext (underline) syntax, convert to ATX first or paste-and-pre-process.
How does the tool handle headings with inline Markdown (links, code, emphasis)?
The heading text is used verbatim for the link label and as input for the slug. Inline Markdown (<code>**bold**</code>, <code>`code`</code>, <code>[links](url)</code>) is preserved in the label but counts as text characters in the slug. Most renderers handle this correctly; check the rendered output to confirm.
Can I generate TOCs for HTML, AsciiDoc, or reStructuredText?
This tool targets Markdown only. For other formats, look for format-specific TOC generators (Pandoc has TOC generation for many input formats; AsciiDoc has built-in <code>:toc:</code> directive).
Why is the H1 skipped by default?
Most documents use H1 as the document title ("README", "My Project"). Including the title in its own TOC creates a noisy first entry that points back to the top of the page. Toggle it off if your structure uses H1 for sections instead of one document title.
Outils liés
03Aperçu Live Markdown→
Rédigez du Markdown et visualisez le HTML rendu en temps réel, puis exportez ou imprimez en PDF.
Générateur de slug→
Transformez une phrase en slug d'URL propre.
Compteur de mots→
Comptez les mots, caractères et lignes dans n'importe quel texte collé.