llms-full.txt — what it is, when to use it, and how to create one

What is llms-full.txt?

llms-full.txt is a companion file to llms.txt, defined in the same specification proposed by Jeremy Howard at Answer.AI in September 2024. While llms.txt provides a curated list of links to your most important pages, llms-full.txt goes further: it inlines the actual content of those pages directly into the file.

The goal is to give AI retrieval systems the full text of your documentation corpus in a single file, without requiring them to follow links and make additional HTTP requests to fetch each page. For large documentation sites, this can significantly reduce the number of network requests needed to load your content as AI context.

llms-full.txt is published at /llms-full.txt at your domain root, alongside your regular /llms.txt file.

llms-full.txt vs llms.txt

Attribute	llms.txt	llms-full.txt
Content	Links to pages with short descriptions	Links to pages + full page content inlined
File size	Small (typically under 50 KB)	Can be large (hundreds of KB to several MB)
Use case	Discovery and curation	Full corpus delivery for retrieval
Staleness risk	Low — just links	Higher — full content must be regenerated when pages change
Crawler behavior	Crawler follows links to fetch pages	Crawler can read full content from one file
Spec status	Defined in llmstxt.org spec	Defined in the same spec, companion convention

Format and structure

The format of llms-full.txt is an extension of llms.txt. The structure is the same — H1 title, optional blockquote, H2 sections with link lists — but below each link, the full Markdown content of that page is included.

A simplified example showing the structure:

# Acme Documentation

> Acme is a REST API for inventory management.

## Documentation

- [Quickstart](https://docs.acme.example/quickstart/): getting started guide.

## Quickstart content

# Getting started with Acme

Welcome to Acme. This guide walks you through your first API call.

## Prerequisites

You will need an Acme account and an API key. Sign up at acme.example...

[... full page content ...]

- [API reference](https://docs.acme.example/api/): complete endpoint reference.

## API reference content

# API Reference

All endpoints accept JSON and return JSON. Authentication uses the Authorization header...

[... full API reference content ...]

In practice, the exact format for content embedding varies by implementation. The key principle is that the full text of each linked page is included in the file so a client reading llms-full.txt does not need to make additional requests.

When to use it

llms-full.txt makes sense when:

• You have a large documentation corpus that you want AI systems to be able to load completely without crawling hundreds of pages. Technical documentation for developer tools is the clearest example.
• Your content is frequently asked about by AI assistants and you want those assistants to have complete, current information without approximation from training data.
• You are building RAG pipelines that need to ingest your documentation. A single large text file is often easier to process than fetching and parsing HTML from many individual URLs.
• Your documentation is auto-generated and you can add llms-full.txt generation to the same build step that generates the docs themselves.

llms-full.txt is less useful for:

• Small sites with fewer than 10–15 pages — a regular llms.txt with direct links is sufficient.
• Sites with content that changes very frequently — the full-text file goes stale faster and is harder to keep current.
• Marketing or editorial sites where the exact wording of every page is less critical than for technical reference material.

Who uses it

The llms-full.txt convention was popularized primarily by Mintlify, a documentation platform widely used by developer-facing companies. Mintlify automatically generates both llms.txt and llms-full.txt for documentation sites hosted on its platform. When a documentation site is built and deployed, the full-text file is generated from the same Markdown source that powers the rendered documentation.

This means a significant portion of the llms-full.txt files in the wild are Mintlify-generated. Other documentation platforms and custom documentation pipelines have also adopted the convention, particularly those used by API-first companies.

Developer tools that explicitly read llms-full.txt include agent frameworks and coding assistants that want to load a complete documentation corpus as session context. Rather than fetching dozens of individual pages, they can read the single full-text file.

Caveats and tradeoffs

Before publishing llms-full.txt, consider these tradeoffs:

• File size. A complete documentation corpus can easily reach several megabytes. This is fine for direct file access, but clients that need to load the entire file into a language model's context window will be constrained by context length limits. Very large files may need to be split or summarized before use.
• Staleness. Every time you update a page in your documentation, your llms-full.txt needs to be regenerated. If your build pipeline does not automatically regenerate it, the file will diverge from your actual documentation. Stale full-text files are potentially more harmful than a stale llms.txt because they contain complete content that an AI might cite verbatim.
• Not all crawlers fetch it. llms-full.txt is a convention, not a standard. Not all AI crawlers or agent frameworks specifically look for it. Many will discover it as a regular file, but may not treat it with any special logic.
• Bandwidth. If your site receives significant AI crawler traffic, serving a multi-megabyte file on every crawl adds bandwidth costs. Consider caching headers to reduce redundant fetches.

How to create one

The most reliable approach is to generate llms-full.txt at build time from the same source that generates your documentation. The general process:

1. Start with your regular llms.txt as the table of contents structure.
2. For each page linked in llms.txt, fetch or read its Markdown source content.
3. Append the full content below the corresponding link in the file.
4. Output the complete file to /llms-full.txt in your public directory.

If you use a documentation platform that supports it (like Mintlify), this may already happen automatically. Check your platform's documentation for llms.txt support.

If you are building a custom generator, keep the Markdown source clean — no unnecessary HTML, no build artifacts, no front matter that should not be in the output. The goal is clean, readable prose that an AI can process directly.

Continue reading

• llms-full.txt reference — the complete spec reference for the extended format.
• llms.txt for API products — where llms-full.txt adds the most value.
• llms.txt for documentation sites — implementation guide for docs platforms.
• Validator — check your llms.txt before generating llms-full.txt.