Markdown TOC Generator
Generate a Markdown table of contents — GitHub / GitLab / plain slugs, configurable depth, auto-dedup.
工具代码会在浏览器中处理所选文件和输入内容，不会将其提交给 TOOLGRID 的处理接口。 TOOLGRID 只衡量工具使用情况，不记录你输入的内容。
- 不上传工具输入至 TOOLGRID
- 不登录
- 复制前先检查
Loading tool…
这个工具能做什么
In-browser Markdown TOC generator. Extracts headings, generates nested anchor-linked TOC, supports GitHub-compatible slug style.
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.
这个工具适合解决什么问题
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.
依赖结果前需要检查什么
- Performance and maximum practical input size depend on browser memory, device speed, and the structure of the input.
- Review the generated result before replacing or publishing an original file.
如果还需要校验、转换或复用结果，可以继续打开相近的浏览器本地工具。
如何使用
01使用场景
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.
使用技巧
- 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.
常见问题
02Does the tool run entirely in my browser?
Parsing and slug generation use browser-side JavaScript. Tool code processes selected files and entered content in your browser and does not submit them to a TOOLGRID processing endpoint. Browser-local processing avoids a TOOLGRID upload path, but it is not a blanket security guarantee.
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.