Are my Markdown documents sent to any server?

No. The parser runs entirely in your browser with JavaScript and the TOC is built in memory. There is no fetch, no upload, and no analytics event carrying your content. Drafts, internal notes, and confidential design docs never leave your device. You can confirm in the DevTools Network tab: no requests fire during TOC generation.

How do GitHub anchor slugs work?

GitHub turns each heading into a URL anchor by lowercasing the text, removing punctuation, and replacing spaces with single hyphens. So "Getting Started" becomes "getting-started" and "What is New in 2026?" becomes "what-is-new-in-2026". Duplicate slugs in the same document are suffixed: "installation", "installation-1", "installation-2". Select the GitHub slug style to match anchors on github.com READMEs.

How is GitLab slugification different from GitHub?

GitLab is slightly stricter: any run of non-alphanumeric characters becomes a single hyphen (so two consecutive symbols collapse), then leading/trailing hyphens are trimmed. GitHub preserves underscores, GitLab collapses them. Practical difference: "node_modules" stays "node_modules" on GitHub but becomes "node-modules" on GitLab. Pick the platform where your document will actually be rendered — anchor links break silently if you pick the wrong style.

Does the generator handle headings inside code blocks?

No — fenced code blocks (``` or ~~~) are skipped. Otherwise a line like # in a Bash sample would be misinterpreted as an H1. The state machine tracks code-fence open/close markers and only counts headings outside fences. Inline backticks (single-line code) do not affect heading detection — only fenced blocks.

What if my document has duplicate headings?

Both GitHub and GitLab suffix duplicates with incrementing numbers. The first "Installation" gets slug "installation", the second gets "installation-1", the third "installation-2", and so on. Our tool follows this convention. The TOC links jump to the correct heading because each heading gets the same anchor when the document is rendered. If you want unique anchors, just use unique heading text.

Why does my TOC start flush even though my document begins at H2?

Base-level normalization handles that. The generator finds the smallest heading level among the included headings and treats it as indent depth zero, so a document that starts at H2 produces a TOC flush to the left margin instead of indented one level. Nested levels stay relative to that base, which keeps the output aligned no matter where the document begins in the hierarchy.

Why might I want a TOC without anchor links?

For plain-text documents (CHANGELOG.md printouts, code review summaries, email replies) the [text](#slug) syntax adds visual noise and the links do not work. Untoggle "Include #anchors" to get a simple indented list of heading text only. Useful for AGENTS.md files, internal-tool readmes, and any context where the TOC is for orientation rather than navigation.

How does this differ from your Markdown Editor?

Markdown Editor is a writing tool with live preview — useful while authoring. TOC Generator is a one-shot extractor — useful when the document is already written and you want a table of contents at the top. The natural workflow: write in the editor, paste the final draft here to extract the TOC, paste the TOC back at the top of the document, repeat as you add headings. Some CMS platforms auto-generate TOCs at render time; this tool is for when they do not.

How are emoji and non-Latin characters handled in slugs?

This tool strips emoji and non-ASCII characters when building GitHub-style slugs, so a heading like "Hello World" works perfectly but "你好 World" reduces to "world". GitHub itself keeps Unicode letters, so on github.com that same heading anchors as "你好-world". If your headings rely on non-Latin scripts or emoji, verify the rendered anchor on the target platform before trusting the link.

Markdown TOC Generator

Q: Is this Markdown TOC generator free?

Yes. The Markdown TOC generator is 100% free with no signup and no usage cap. Paste any number of headings and copy the linked table of contents as often as you like. All three slug styles and every depth option are available.

Generate a Markdown table of contents from your headings, with linked anchor slugs in GitHub, GitLab, or Pandoc style. Set the depth range, choose a numbered or bulleted list, and copy the result. Free and 100% in your browser.

Min levelMax levelSlug styleIndentNumbered listInclude #anchors

Markdown input(14 total headings, 14 included)

Table of contents

- [Toolk Project Documentation](#toolk-project-documentation)
  - [Getting Started](#getting-started)
    - [Prerequisites](#prerequisites)
    - [Installation](#installation)
    - [First Run](#first-run)
  - [Architecture](#architecture)
    - [Frontend Stack](#frontend-stack)
    - [Component Library](#component-library)
      - [Color Tokens](#color-tokens)
      - [Typography](#typography)
  - [Contributing](#contributing)
    - [Code Style](#code-style)
    - [Pull Requests](#pull-requests)
  - [License](#license)

Auto-Indented Nesting

Each heading depth (#, ##, ###) becomes one level deeper in the list output. Base level is normalized so the TOC starts flush regardless of the source's top heading.

Three Slug Styles

GitHub (default), GitLab, and Pandoc — pick the platform where the document will be rendered. Duplicate slugs auto-suffix with -1, -2, -3 (the GitHub convention).

Configurable Depth

Restrict to top-N levels (e.g. include only H1-H3 and skip the leaf-level sub-headings). Choose ordered (numbered) or unordered list output, 2 or 4 space indent.

100% Client-Side

Markdown documents may contain drafts, internal notes, or sensitive prose. The parser runs entirely in your browser — nothing leaves the page.

Markdown TOC Generator: build a linked table of contents from your headings

A Markdown TOC generator reads the #, ##, and ### headings in your document and outputs a nested, linked table of contents you paste at the top. Each entry uses the anchor slug that GitHub, GitLab, or Pandoc generates — lowercased, hyphenated, punctuation stripped — so the links jump to the right section. Pick a depth range and list style, then copy. It is free, and runs 100% in your browser.

How to generate a Markdown table of contents

Paste your Markdown into the input pane, or press Sample to load an example document.
Set Min level and Max level to choose which heading depths appear (default H1 to H4).
Choose a Slug style — GitHub, GitLab, or Pandoc — to match where the document will render.
Pick Indent (2 or 4 spaces), toggle Numbered list for ordered output, and toggle Include #anchors off for a plain-text list.
Press Copy on the Table of contents pane and paste the result at the top of your README or post.

What is an anchor slug, and how is it generated?

When a Markdown renderer turns a heading into HTML, it adds an id attribute so the heading can be linked directly with a #fragment URL. That id is the slug. The WHATWG HTML standard defines how a browser scrolls to that fragment, but the slug text itself is decided by the renderer. GitHub's rule is the most widely copied: lowercase the heading, drop punctuation, and replace each run of spaces with a single hyphen. The reference implementation is github-slugger, which the GitHub team mirrors for README anchors.

This tool also nests by heading level: an ## under an # indents one step, an ### two steps, and so on. It detects the smallest level used and treats it as depth zero, so a document that starts at H2 still produces a flush-left TOC. Duplicate slugs are disambiguated with -1, -2, -3 suffixes, exactly as GitHub does.

How each platform slugifies headings

Platform	Slug Rule	Notes
GitHub	lowercase → replace whitespace with hyphens → drop everything except [a-z0-9-_]	Used by README anchors on github.com. Most permissive about underscores.
GitLab	lowercase → replace any non-alphanumeric run with single hyphen → trim hyphens	GitLab pages and wiki anchors. Stricter — collapses runs of punctuation.
Pandoc	Same as GitHub for common cases	Used by Pandoc-rendered HTML and many static-site generators.

Worked examples: heading → slug → TOC line

Plain heading · GitHub style

## Getting Started → - [Getting Started](#getting-started)

Punctuation · GitHub style

### What is New in 2026? → [What is New in 2026?](#what-is-new-in-2026)

Underscores · GitHub vs GitLab

## node_modules → #node_modules (GitHub) vs #node-modules (GitLab)

Edge case · emoji & non-Latin headings

A heading like ## 你好 World reduces to #world in this tool, because it strips non-ASCII characters. On github.com the same heading anchors as #你好-world, since GitHub keeps Unicode letters. For non-Latin or emoji headings, confirm the rendered anchor on the target platform before relying on the link.

Where TOC generation helps

README and documentation

GitHub renders Markdown READMEs with auto-anchored headings — paste your draft and generate the TOC to put at the top.

Blog posts

Long-form posts benefit from a TOC for scannability. Generate one quickly from your draft headings.

Technical specifications

RFC-style specs and design docs need a TOC. Generating it deterministically prevents drift between body and TOC.

Wiki pages

GitLab and Confluence wikis use slug-based anchors. Pick the right slug style for your platform.

Documentation sites

Static-site generators (Docusaurus, MkDocs, VitePress) can auto-generate TOCs at build time, but a generator helps when porting drafts.

The slug detail that silently breaks anchors

Most TOC generators advertise "GitHub-compatible" slugs but quietly drop characters GitHub keeps. This tool's GitHub rule allows only a-z, 0-9, hyphen, and underscore, then strips everything else. Real GitHub, per github-slugger, preserves Unicode letters — so привет stays привет on github.com but collapses here. For purely ASCII headings the two match exactly; the divergence only appears with accented, Cyrillic, CJK, or emoji text.

The practical fix is the same advice that prevents most broken anchors: keep heading text ASCII and unique. Duplicate headings auto-suffix with -1, -2, which makes a link target shift the moment you insert or remove a section above it. Unique, plain headings produce stable slugs that survive reorders.

Four TOC authoring tips

1. Stop at H3 for most documents

H4 and deeper rarely belong in a top-level TOC. Set Max level to H3 for blogs, H4 for long technical specs.

2. Keep headings concise

Long headings produce long slugs and ugly anchor URLs. Aim for 2 to 6 words and move detail to the body text.

3. Avoid duplicate heading text

Duplicates auto-suffix with -1, -2, which produces fragile anchors that shift when you insert or remove sections.

4. Regenerate after big edits

If you reshuffle sections, the TOC at the top drifts. Re-paste the document and re-extract — it takes seconds.

Runs 100% in your browser

Your Markdown never leaves your device. The parser walks the input in JavaScript inside the page and builds the TOC in memory — no uploads, nothing leaves your device. I tested it on README drafts, a 200-heading spec, documents that start at H2, files with fenced ``` code blocks containing # comments, and duplicate-heading edge cases across all three slug styles. Headings inside code fences are correctly skipped, and the output stays instant even on large documents.

Frequently asked questions

Is this Markdown TOC generator free?

Yes — 100% free with no signup and no usage cap. All three slug styles and every depth option are available.

Are my Markdown documents sent to a server?

No. The parser runs entirely in your browser and the TOC is built in memory. There is no fetch, no upload, and no analytics event carrying your content.