What is llms-full.txt?

What is llms-full.txt?

llms-full.txt is a companion file to llms.txt that contains the actual content of the pages referenced in llms.txt, concatenated together as a single Markdown document. It lives at the root of a domain: https://example.com/llms-full.txt.

Where llms.txt is a curated index (a table of contents), llms-full.txt is the full corpus — the complete readable content, ready to be fed into an LLM context window in a single HTTP request.

llms-full.txt vs llms.txt

The two files solve different problems:

• llms.txt (the index). A short Markdown file with section headings and curated links. Small (typically 1–10 KB). Easy to maintain. Tells an LLM client which pages to read. The client must then follow the links and fetch each page separately.
• llms-full.txt (the corpus). A larger Markdown file that inlines the content of those pages. Can be 50 KB–5 MB+ depending on the size of the documentation. The client loads a single URL and gets everything at once — no further crawling required.

For most sites, publishing both is the recommended approach: llms.txt for lightweight discovery, llms-full.txt for clients that need the full corpus pre-loaded.

File structure

There is no strict schema for llms-full.txt beyond being valid Markdown. The dominant convention (established by Mintlify and followed by Anthropic, Vercel, and others) is:

1. Each included page starts with its URL as a level-2 heading or a code block header.
2. The full Markdown content of the page follows immediately below.
3. A horizontal rule (---) or a blank line separates successive pages.

A minimal example with two pages inlined:

# example.com — full content\n\n## https://example.com/getting-started/\n\n# Getting started\n\nWelcome to Example. To install...\n\n---\n\n## https://example.com/api-reference/\n\n# API reference\n\nBase URL: https://api.example.com/v1...\n

Who publishes it?

The llms-full.txt convention was popularized by Mintlify, which auto-generates both llms.txt and llms-full.txt for every documentation site it hosts. Anthropic publishes one at docs.anthropic.com/llms-full.txt — it is several megabytes and contains the full API reference, guides, and model documentation as concatenated Markdown.

Other early adopters include Cloudflare (developer documentation), Vercel, and Stripe. The pattern is consistently documentation-heavy developer tools sites where LLM-assisted coding is a primary user behavior.

How to create llms-full.txt

There are three common approaches:

1. Static generation at build time. Write a build script that reads the same Markdown sources your site uses, strips HTML-specific elements, and concatenates them into /public/llms-full.txt (or the equivalent output directory for your framework). This is what Mintlify and most static site generators do.
2. Dynamic server route. For frameworks that support server-side rendering, create a route at /llms-full.txt that fetches your content at request time, concatenates it, and returns a plain-text response. Slower per request but always fresh.
3. Manual maintenance. For small sites, you can maintain llms-full.txt by hand: copy the Markdown source of your key pages into a single file and update it when content changes. Not scalable for large documentation, but perfectly valid for a 5-page site.

When to publish llms-full.txt

Publish llms-full.txt if your site meets at least one of these conditions:

• You have technical documentation that developers regularly ask AI assistants about.
• Your content is spread across many pages that would be expensive for an LLM client to crawl individually.
• You want to be usable in RAG pipelines or AI agent workflows that expect a single-URL corpus.
• You are a SaaS or API provider whose users may ask coding questions to Cursor, Windsurf, or similar tools.

If your site has fewer than 10 pages of meaningful content, a well-maintained llms.txt alone is probably sufficient. The extra surface area of llms-full.txt earns its keep at larger documentation scale.

Caveats and tradeoffs

• File size. llms-full.txt can become very large. A 500-page documentation site may produce a 10+ MB file, which exceeds the context window of most current LLMs. Consider including only the highest-signal pages rather than the complete site.
• Maintenance overhead. Unlike llms.txt (which only contains links), llms-full.txt duplicates content. If pages change without a re-build trigger, the file becomes stale. Automate the generation step.
• No standardized schema. Unlike llms.txt, which has a defined structure at llmstxt.org, llms-full.txt format is a community convention without a formal spec. Structure your file clearly so any client can parse it.
• Public exposure. Everything in llms-full.txt is public by definition. Do not include content you would not otherwise publish at a public URL.

Continue reading

• What is llms.txt — start here if you are new to the convention.
• How to create llms.txt (and llms-full.txt) — templates and per-stack guides.
• Comparison: llms.txt vs robots.txt vs sitemap.xml — when to use each file.
• Validator — check your llms.txt file against the spec.