llms.txt Generator

A technical reference, an installation guide, and a migration guide can all be correct while answering different questions. A useful documentation index explains which one to read. The llms.txt community proposal provides a small Markdown file for that job, giving large language models (LLMs) and agents an overview of a site and links to selected resources.

Markdown expresses headings, links, and other formatting in plain text. An llms.txt file begins with a main heading, called an H1, naming the project or site. That name is the only required part. A short blockquote can summarize the project, introductory text can explain important context, and section headings, called H2 headings, can group links into subjects such as documentation or examples. Each link has a readable name and may include a note explaining what the destination contains.

Curation determines how useful those links become. For a software project, an installation guide may be the right starting point for a new user, while an application programming interface (API) reference answers questions about requests and responses. Version information matters when current instructions differ from older releases. A short note such as “Authentication methods and request limits” tells the reader more than repeating “API documentation.”

• Include the pages that answer the main questions about the project, with clear titles and enough context to choose between them.
• Keep detailed explanations in the linked documents. Use the overview for scope, prerequisites, version guidance, and distinctions that affect which document to read.
• Leave out accidental duplicates, obsolete instructions presented as current guidance, and links that add no useful information for the intended reader.

An Optional section conventionally holds secondary reading, such as background material or release history. In version 2 of the proposal, that name carries no automatic exclusion rule. A consuming agent decides what to follow, and the section remains part of the file.

Several neighboring files serve different publishing needs:

sitemap.xml

Lists site URLs for discovery by crawlers. It does not provide the same curated explanations of which resources answer particular questions.

robots.txt

Communicates crawler access rules. An llms.txt overview does not grant access or replace those rules.

llms-full.txt

A separate convention used by some documentation platforms to collect full page content into one document.

Clean Markdown versions of linked pages can make their content easier to consume, but adding .md to an address does not create such a page. Destinations need to exist and contain the material their titles promise. A well-formed index can still point to missing pages or outdated advice.

The proposal makes no guarantee that an agent will discover, use, or quote a file. Its practical value comes from a maintained selection of useful material, with the overview and linked documents updated together as the project changes.

How to Use This Tool:

Choose Build file to author from fields, or Check existing to inspect a file you already have. The file and findings update as you edit.

Build from fields

1. Replace Site or project name with your own name. Add a Summary and Introductory details when they help explain the project, keeping headings out of the details.
2. Edit Sections and links to replace the sample resources. Give each resource a meaningful name, its URL, and any useful notes. Reorder sections and resources within their sections to establish the intended reading order.
3. Set Base URL for relative links under Advanced if relative destinations should become full URLs. Leave it blank when no conversion is needed. A trailing slash makes the base a directory.

Check or import existing material

1. Paste an existing file into Existing llms.txt in Check existing. To inspect the current builder output instead, select Check this file as source from the builder.
   Changing Operation alone does not transfer the builder output into the checked text. The base URL affects only Build file.
2. Preview material before importing it into fields. Use Preview in builder for the checked file, or paste an llms.txt file, URL list, or sitemap XML into Import llms.txt or links and select Preview import. The preview shows the detected format and section and link counts while leaving the current fields unchanged. Choose Input format explicitly if automatic detection selects the wrong type.
3. Apply the preview with Replace builder fields for an existing llms.txt file, or Append links for URL and sitemap imports. Replacement asks for confirmation. Appended links enter an Imported resources section with provisional names and empty notes, ready for curation.
   If an llms.txt import is refused, inspect it in Check existing and correct the reported content before importing. Rebuilding changes formatting, and any previously entered base URL remains in effect.

Review Validation findings before publishing. Follow the indicated line and next action for each error, then assess the warnings. If the summary says Check the inputs, correct the named input problem, such as a missing project name or an exceeded limit, to restore the results.

Use Copy llms.txt or Download llms.txt for the reviewed text. Publish it yourself in the directory it describes, then open the published file and its destinations to check what readers will receive.

Interpreting Results:

The headline follows the most serious finding. Notes provide context without increasing the error or warning counts.

The Check column distinguishes three reasons for a finding:

• Format concerns the supported document structure.
• Publishing covers destination restrictions and advice such as duplicate or relative links.
• Compatibility flags differences in the legacy Python parser. These warnings do not add requirements to the proposal.

The first overall finding summarizes the individual checks and does not add another error to the count. The resource total and Link inventory include recognized entries even when they are duplicates or have destination errors.

Curation balance groups those entries by section and whether they have notes. It measures the presence of notes, not their accuracy or usefulness, and gives no quality score. There is no requirement for equally sized sections.

A successful structure check does not test whether a destination responds, serves Markdown, or contains current information. Inspect the actual destinations and, when compatibility matters, try the file with the agent or parser that will consume it. The initial example can pass the checks while still needing all sample content replaced.

Technical Details:

The v2 proposal dated 10 August 2026 organizes an overview before its resource lists. Position carries meaning: introductory prose belongs before the first resource heading, while the sections after it contain links. These checks cover hash-prefixed headings and single-line inline links rather than every construction supported by a general Markdown reader.

Rule Core

The following rules explain the supported structure.

Alternative Markdown forms, such as underlined headings or reference-style links, are outside this checker's supported grammar. Missing summaries, missing resource notes, and a file without resources receive notes. An empty resource section receives a publishing warning. These distinctions avoid treating every recommendation as required syntax.

Transformation Core

Building assembles the name, summary, details, and ordered resource lists into Markdown. Summary lines receive a blockquote marker, resource lists use dash bullets, and titles and notes are reduced to single lines. Backslashes and square brackets in link names are escaped, literal URL parentheses become %28 and %29, and the generated file ends with a newline.

With an absolute HTTPS base pointing to a site's /docs/ directory, start.md resolves to that site's /docs/start.md. A leading slash instead resolves from the site root.

Leaving the base blank preserves relative destinations. The following generated file keeps one directory-relative link and one root-relative link:

# Atlas Docs

> Documentation for the Atlas project.

Use the current release for new integrations.

## Docs

- [Getting started](start.md): Install and send a first request

## Optional

- [Release history](/changelog.md)

This produces 2 resources in 2 sections, 0 errors, and 2 warnings, with Review warnings as the summary. Each relative destination produces one publishing warning. Notes identify the unannotated release-history link and explain the Optional convention.

Adding the directory base described above turns both destinations into full addresses and removes those two warnings. The summary becomes Structure checked when no other warnings or errors remain.

Destination rules

HTTP and HTTPS addresses and relative paths are accepted by the local publishing checks. Addresses containing credentials, other URL schemes, and protocol-relative addresses beginning with // are rejected. Surrounding whitespace is trimmed for checking. Spaces and selected unsafe characters within a destination, including backslashes, produce publishing errors. These are local destination restrictions, not additional requirements of the community proposal.

An optional absolute HTTP(S) base resolves relative builder destinations. A base ending in a slash supplies a directory. Without that slash, the last path segment is replaced when a relative path is joined. Path segments such as .. move toward a parent directory. Already absolute links can point to other sites, and their path case, query strings, and fragments are retained. The builder does not add a Markdown extension.

Duplicate comparison ignores letter casing in the scheme and host. An absolute address ending at the host matches the same address with a trailing slash. No slash is inserted before a query string or fragment. Path case, query strings, and fragments remain significant. Consequently, differently spelled addresses can still refer to the same real page without being recognized as duplicates. Repeated entries remain in the file and its resource counts until the author removes them.

Legacy parser compatibility

The published reference Python parser has narrower parsing behavior than the proposal. Compatibility findings call attention to cases that should be tested with the actual consumer:

• A heading-only file or a leading byte-order mark can fail older parsing expectations even though the proposal permits them.
• Multiple summary lines or a blockquote after other introductory text may not be read as the intended summary.
• Star and plus bullets are recognized locally, while the legacy link parser expects dash bullets. Escaped brackets in link names also need a compatibility check.
• Literal parentheses in URLs can cause the legacy parser to stop reading a destination too early.
• Repeated section names can overwrite earlier sections in the legacy parser. Distinct names preserve the intended grouping.

Imports, preservation, and limits

URL-list imports read one destination per nonempty line. Sitemap imports read a pasted urlset and the loc value in each direct url entry. Malformed XML, missing locations, sitemap indexes, and document type definition (DTD) or entity declarations are rejected. Only the supported location structure is checked, so acceptance does not establish full sitemap-schema validity. Imported resource names are derived from URL text, and notes start empty.

Checking retains the entered file apart from normalizing Windows or older Mac line endings to line feeds. It does not repair the text. Importing an existing llms.txt into fields requires supported content without errors and regenerates its formatting. Detected unsupported content is refused instead of being silently dropped. Keep the original text when exact formatting matters.

These local limits keep editing and checking bounded. The individual field limits apply to the builder and field imports. The llms.txt proposal does not impose these limits.

Check existing applies its total text and line limits, including blank lines, without imposing the builder's section, resource, or individual field limits on the parsed document. Large collections in the builder can reach the aggregate editing limit before the individual field limits. Findings use line numbers starting at 1, and counts involve whole entries without rounding.

Publishing scope

Under v2, /llms.txt describes the site root and /docs/llms.txt describes the pages below /docs/. When scopes overlap, the most specific file applies. The proposal also recommends discovery links identifying a page's Markdown alternative and its applicable llms.txt file. Hosting the file and configuring those discovery links remain separate publishing tasks.

Privacy Notes:

Generation, checking, and pasted imports run in your browser. They do not fetch listed URLs, retrieve page titles, crawl a site, or follow sitemap references.

• Restorable page URLs may contain entered fields and checked text. Treat a shared form URL as potentially sharing those contents.
• Opening Curation balance can load charting assets from an external host. This is separate from checking the destinations in your file.
• Entered Markdown is displayed as text rather than rendered as HTML.

Worked Examples:

References:

• The /llms.txt file, v2, Jeremy Howard, updated 10 August 2026.
• Changes to the llms.txt proposal, llms-txt, August 2026.
• Python source and reference parsing behavior, llms-txt.
• llms.txt and llms-full.txt, Mintlify.