llms.txt validator: check your file line by line

The format, as the proposal gives it

The llms.txt proposal by Jeremy Howard (llmstxt.org, first published 3 Sep 2024, revised as v2 in August 2026, read 24 Sep 2026) is a Markdown file whose parts come "in the specific order":

1. an optional byte-order mark (BOM);
2. an H1 with the name of the site or project, "the only required section";
3. a blockquote with a short summary;
4. zero or more Markdown sections "of any type except headings" with more detail;
5. zero or more H2 sections, each a "file list": a Markdown list whose items hold a required [name](url), then optionally a : and notes.

# Acme Tents

> Ultralight tents and tarps, sold by mail order across the EU.

Prices are in euros and include VAT.

## Products

- [Ultralight 2](https://example.com/tents/ultralight-2.md): two-person tent, 1.1 kg

## Optional

- [Company history](https://example.com/about/history.md)

An H2 named "Optional" holds secondary links an agent can skip. Since v2 that is a convention only; the proposal's changes page says it no longer carries "mechanical semantics". v2 also lets a file sit at a sub-path, such as /docs/llms.txt, covering the pages under that path, and it suggests rel="describedby" links pointing to it.

Errors: the file does not follow the format

• No H1, reported at the first line with text. A line like #Acme is not a heading in Markdown: the space after # is required, and the checker says so.
• The H1 is not the first line with text: YAML front matter, an HTML comment or a stray line above the title.
• More than one H1, reported at each extra one. Sections of links take ## .
• A list item in an H2 section that is not a well-formed link, for example - [Docs](https://example.com/docs with its ) missing, - Docs: https://example.com/docs with no [name](url) at all, [Docs] (url) with a space, or a reference-style link.
• A link whose scheme is not http or https: javascript:, data:, mailto:, ftp:. An agent cannot fetch them, and a javascript: link runs code if clicked in a Markdown viewer.

Warnings: allowed, or not addressed, but probably not what you meant

• The blockquote is not directly after the H1, so it reads as detail text, not as the summary.
• A heading (H3 to H6) in the free text before the first H2, where the proposal allows anything "except headings".
• An H3 or deeper heading inside a file list.
• A relative URL (/docs/a.md) or protocol-relative one (//cdn…), and a URL listed twice (the warning names the first line).
• An H2 section with no link lines, and text in a section that is not a list item.
• * or + bullets. Markdown allows them and the proposal only says "a markdown list", but every example it gives uses - , and a parser written from the examples may look only for that.
• A second "Optional" section. A line of --- or === directly under text, which Markdown turns into a heading.

Info

The number of characters, lines, links and sections; a BOM; CRLF (Windows) or bare CR line endings; trailing spaces; no summary; a missing final newline. None of these break the format. Line endings and a BOM survive only when you drop or open a file: a pasted text box always holds LF endings.

What the proposal does not say

The checker does not invent rules for these. Where it warns, the warning says why.

• Whether relative URLs are allowed. All its examples use full https:// URLs.
• How big the file may be. It says only that the file "stays small enough to fit in context".
• Which text encoding to use; it mentions only the optional BOM.
• Whether "Optional" must be the last section, or whether its case matters. The checker treats ## optional as the same section.
• Whether section names must be unique, whether a section may be empty, and whether a file list may hold text or sub-headings.
• Whether the same URL may appear twice, and whether numbered lists count as file lists. The checker accepts 1. [name](url) as a link line.

The cleaned version

It changes four things and nothing else: * and + bullets become -; runs of blank lines become one, with one blank line around each # heading; trailing spaces and tabs are removed; line endings become LF. Fenced code is left alone apart from trailing spaces, and a BOM is kept. It does not fix errors, reorder anything or touch your wording. Cleaning a cleaned file changes nothing. The test suite runs the generator's output for three sets of choices (a name only; a full file with summary, details, two sections and Optional; names full of * _ [ ] and backticks) through this checker: each comes back unchanged, with no errors and no warnings.