Markdown TOC Generator
Generate a Markdown table of contents from any heading structure — GitHub / GitLab / plain anchor styles, configurable depth.
이 도구를 사용하는 이유
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.
사용 방법
03복사 전 빠른 확인
03Confirm the input is the format you intended.
Scan the result before using it in a document, URL, config, or message.
Copy only the output you need.
사용 사례
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.
자주 묻는 질문
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.
관련 도구
03Markdown 실시간 미리보기→
Markdown을 작성하면서 렌더링된 HTML을 실시간으로 확인하고, HTML이나 PDF로 내보낼 수 있습니다.
슬러그 생성기→
문구를 깔끔한 URL 슬러그로 변환합니다.
단어 수 세기→
붙여넣은 텍스트의 단어, 문자, 줄 수를 셉니다.