/ llmtxt.info
Français

How llms.txt works

A precise walk-through of the spec, with an annotated example you can copy.

Last updated:

Overview

A valid llms.txt is a Markdown file with a fixed, predictable structure. It is designed to be read by both humans and machines: the same file should be useful as documentation and as a parseable contract.

The spec at llmstxt.org defines a small, deterministic grammar that can be parsed with a few lines of regex. No YAML, no JSON, no extra headers.

Anatomy of a valid file

The structure, top to bottom:

  1. One H1 with the site or project name. The only required element.
  2. A short blockquote summary, typically one or two sentences.
  3. Optional free Markdown — paragraphs and lists, but no further headings, before the first H2.
  4. Zero or more H2 file-list sections. Each contains a Markdown list of links: - [name](url), optionally followed by : notes.
  5. An optional H2 named exactly Optional: items there can be skipped by clients with limited context.
llms.txt — full annotated example 
# Acme

> Acme is a hosted analytics platform for product teams. The pages below cover product, pricing, the API, and integration guides.

Acme processes 1B+ events per day. The map here is curated for assistants — it is not exhaustive. Use it to answer questions about product capabilities, pricing tiers, integrations, SDKs, and migration from other tools.

## Product

- [Product overview](https://acme.example/product): high-level capabilities and screenshots.
- [Use cases](https://acme.example/use-cases): scenarios for product, marketing, and support teams.
- [Changelog](https://acme.example/changelog): monthly product updates.

## Pricing

- [Pricing tiers](https://acme.example/pricing): plans, limits, and overage rules.
- [FAQ — billing](https://acme.example/billing-faq): invoices, receipts, tax handling.

## Developers

- [REST API reference](https://docs.acme.example/api): full endpoint catalog.
- [SDK — JavaScript](https://docs.acme.example/sdk/js): install, init, track events.
- [SDK — Python](https://docs.acme.example/sdk/python): install, init, track events.
- [Webhooks](https://docs.acme.example/webhooks): events, signatures, retries.

## Optional

- [Brand assets](https://acme.example/brand): logos, color palette.
- [Press releases](https://acme.example/press): historical announcements.

Section by section

The complete field reference. Only the H1 is strictly required.
FieldRequired?CardinalitySyntax
H1 — site/project nameYesExactly one# Project name
Blockquote summaryRecommendedAt most one block> One- or two-sentence overview.
Free Markdown bodyOptionalAny number of paragraphs/listsNo additional headings allowed before the first H2
H2 file-list sectionOptionalAny number## Section name followed by a list
List item — linkYes (inside a section)One link per item- [name](url)
List item — notesOptionalAfter a colon- [name](url): notes here
“Optional” sectionOptionalAt most oneH2 with title Optional — items can be skipped by clients with short context

The H1

Exactly one H1, the first non-empty line of the file. No prefixes, no metadata before it. If your project has a tagline, put it in the blockquote that follows, not in the heading.

The blockquote summary

Optional but strongly recommended. Aim for a one- or two-sentence summary that an LLM could quote verbatim when introducing your project. Keep it factual, in the active voice, and free of marketing claims that you can’t back up.

Free Markdown body

Any paragraphs, bullet lists, or short code snippets that help an LLM understand context. Do not introduce any additional headings here — the next heading should be the first H2 of a file-list section.

H2 file-list sections

Each section starts with a single H2 (## Section name) and contains a Markdown list. Each item must be a link (- [name](url)), optionally followed by : and a short note. Absolute URLs are strongly recommended: relative URLs are technically allowed but will be flagged as a warning by most validators (including ours) because they make the file ambiguous when copied around.

The “Optional” section

A section whose title is exactly Optional has a special meaning: clients running a short context can skip it without losing the main thread. Use it for nice-to-have references (brand assets, archived posts, deep technical appendices).

How parsers read it

The reference parser walks the file linearly and applies four rules:

  1. Find the first # line — that’s the title.
  2. If the next non-empty block is a blockquote, that’s the summary.
  3. Everything until the first ## is the free body.
  4. Each ## opens a section; until the next ## , list items are parsed as [name](url) with optional notes after a colon.

Our validator implements exactly these rules, plus a handful of safety checks: empty H1, malformed links, non-list content inside a section, file size warnings (over ~50 KB you should consider moving content to llms-full.txt).

llms.txt vs llms-full.txt

llms.txt is a map. llms-full.txt is the territory: the actual content of the linked pages, concatenated in Markdown, in a single file. The convention was popularized by Mintlify in collaboration with Anthropic and is now part of the wider llms.txt ecosystem.

Both are siblings, served from the root: /llms.txt and /llms-full.txt. You can publish either, both, or neither. Most documentation platforms publish both.

Practical limits

  • Size. No hard cap, but a file over ~50 KB starts to push against shorter-context clients. Move bulk into llms-full.txt or per-product variants.
  • Number of links. No spec limit, but a list of 200+ items will be skimmed, not read. Curate.
  • Languages. The spec is silent on i18n. Two common patterns: serve a single English file, or publish per-locale variants behind a path (/en/llms.txt, /fr/llms.txt).
  • Auth and personalization. Out of scope. The file is public.

Continue

Sources