llms.txt Generator — Manual

Back to the overview: llms.txt Generator · Open the tool: www.jpkc.com/tools/llms/

This manual documents the llms.txt Generator in full: every input field of the generator, how your input becomes Markdown, the server snippets, what the live checker validates (with all its rules and the link check), the format reference, and the technical limits. The tool's interface is in English — tab, field, and button names appear here exactly as you'll see them in the live interface.

What an llms.txt is

The llms.txt is a proposed standard (by Jeremy Howard / fast.ai, documented at llmstxt.org (opens in a new tab)): a Markdown file at /llms.txt or under a subpath that gives AI agents curated, accurate context about your content. The tool follows version v2 (August 2026). In its Tips tab, under "How Agents Use llms.txt", it describes three aspects:

• On demand — agents read the llms.txt when they need information while helping someone: coding agents for API docs, chat assistants for product questions. It serves to answer requests; it is not a crawler or ranking signal.
• Follow the links — the file stays small enough for the context window; the detail lives behind the links. Agents use your notes to pick which pages to fetch — which is why it pays to link clean Markdown versions (page.html.md).
• Discovery — pages can point to their llms.txt with rel="describedby" and to their Markdown version with rel="alternate" type="text/markdown" (v2). According to the tool, Chrome Lighthouse also checks for the file in its agentic-browsing audits.

The five tabs at a glance

The tool is organized into five tabs: Generator (form → Markdown, with check results and server snippets), Check (live validator with link check), Examples (four templates), Tips (best practices), and Reference (the format spec). Generator and Check are the two working tools; Examples, Tips, and Reference are reference content and work without any input.

The Generator tab

The generator is two-column: the form on the left (Configure your llms.txt), the output editor with the finished Markdown on the right, followed by the check results and the Serving & discovery card. Every input updates the output live (with a 250-millisecond delay). The output editor is a read-only ACE editor with Markdown highlighting — so you always edit via the form, never the Markdown directly.

Name (required) and summary

• Project / Site Name (required, red asterisk) — becomes the H1 heading: # Name. According to the spec, this is the only required element. If you leave the field empty, the generator does not insert a placeholder: it omits the H1 and reports an error below the output saying that at least the name is needed.
• Summary (recommended) — becomes the blockquote right after the title: > your summary. One or two sentences with the key facts; the tool describes it as what agents read first. Without it the file is still valid — the validator only warns.

Name and summary are each collapsed onto a single line: line breaks and runs of spaces turn into one space.

Details (optional)

The Details field takes any Markdown that goes after the summary and before the first section: paragraphs and lists, such as the audience, the purpose, or how to read the linked files. Headings aren't allowed here, because they would break the structure. If a line starts like a heading (# to ######), the generator writes it escaped as \# and points this out below the output; lines inside code blocks are left untouched. Left empty, the block is omitted entirely.

Sections, links, and subsections

The dynamic Sections & Links area is the core. Via Add Section you create as many sections as you like; each becomes an H2 heading (## Name). Every section has a name field, arrow buttons to move it up or down, and a button to remove it. Within a section:

• Links via Add Link: three labelled fields per row — Name, URL (e.g. https://example.com/docs/start.md), and Notes (optional, the note on the link). The output is - [Name](URL): Notes; without a note the colon is dropped. Every link row has its own arrow buttons and a remove button.
• Subsections (H3) via Add Subsection (H3): a section can hold subgroups with their own heading (### Name) and their own link list — again with arrow buttons and a remove button. Subsections are output after the section's direct links. Note that H3 is not part of the spec but a generator extension. Agents read it without trouble, but the Python reference parser treats every H3 as a section of its own.
• Text under the heading via Add Text: this opens a field labelled "Text under the heading (not part of the spec)". The text is output before the section's links. The spec expects nothing but link lists under an H2; agents read the text anyway, the Python reference parser doesn't — the tool flags this as an info note. Headings in the text are escaped as \#, just like in the details.
• Reordering: move sections, subsections, and links with the arrow buttons (Move up / Move down) — this works with the keyboard and on touch devices, too. Sections can additionally be dragged into a new order with the mouse by their grip handle (the dot grid on the left).

Empty sections (no name, no content) and empty subsections don't appear in the output. A section with content but no name gets an empty ## heading, and the generator warns about it.

What the generator cleans up as it writes

So that your input can't accidentally break the structure, the generator tidies up as it writes:

• Links without a URL are left out; a warning below the output names the link and its section.
• Links without a name use the URL as their name (info note).
• Square brackets and backslashes in the name are escaped with \ (\[, \], \\).
• Spaces, parentheses, and angle brackets in URLs are percent-encoded (%20, %28, %29, %3C, %3E) — otherwise the reference parser would misread the link.
• A link's name, URL, and note are each collapsed onto one line, and trailing whitespace is removed.

The llms-full.txt reference

The optional llms-full.txt URL field links to a combined full-content file (see below). Underneath is a field for the link's notes; if you leave it empty, the generator uses the default text "The complete documentation in one file". The link goes into the ## Optional section: if a section by that name already exists, it's appended there; otherwise the section is created at the end. The result looks like this:

## Optional

- [llms-full.txt](https://yourdomain.com/llms-full.txt): The complete documentation in one file

The form points out that llms-full.txt is a convention and not part of the spec.

Link targets: Markdown versions

The Link targets select decides where the links point. llms.txt v2 recommends linking clean Markdown versions of your pages:

Both Markdown modes follow the same rules: a path without an extension gets .md appended (/docs/start → /docs/start.md), and a bare domain is treated like a directory. URLs that already end in .md or .txt, and other files such as PDFs or JSON, stay as they are; query strings and fragments are preserved. Your form fields don't change — only the output is rewritten. A note reminds you that these URLs must actually exist on your server; you can test them afterwards with the link check in the Check tab.

Output: Copy, Download, Reset

Three buttons sit above the editor:

• Reset — after a confirmation prompt, restores the form to its default state (a single empty section named "Documentation") and clears the saved state.
• Copy — copies the generated llms.txt to the clipboard.
• Download — saves it as a file named llms.txt (plain text, UTF-8). Download and Copy only warn when the output is completely empty. The pre-filled "Documentation" section alone already produces output (## Documentation), so the warning only appears once you've also cleared or removed that section.

Check results below the output

Below the editor, the generator continuously checks the output with the same validator the Check tab uses. At the top sits a badge for the Python reference parser: green "Python reference parser reads it" if the llms-txt Python package can read the file, otherwise grey "Python reference parser can't read it (optional tool)". Grey is not an error — since v2 that tool is no longer part of the proposal. Below the badge come the messages, each with an icon for its level: first the validator's errors and warnings, then the generator's own notes (for example on links that were left out, escaping, or section text), and finally the info notes. The rules behind them are listed under What the validator checks.

Serving & discovery: server configuration

The Serving & discovery card below the check results produces configuration snippets so the file is served correctly and can be found from your pages. The tool reminds you that the file belongs at the path it describes — /llms.txt covers the whole site, /docs/llms.txt only /docs/.

• Path — the directory the file lives in (default /). Only letters, digits, and . _ ~ - between slashes are allowed; the tool adds missing leading and trailing slashes. An invalid path is marked red.
• nginx / Apache / HTML — toggle for the kind of snippet; Copy copies it.

For the path /docs/, the nginx toggle produces this block for your server block:

# nginx (server block): serve llms.txt and markdown pages as UTF-8 text
location = /docs/llms.txt {
    types { }
    default_type "text/plain; charset=utf-8";
}
location ~ \.md$ {
    types { }
    default_type "text/markdown; charset=utf-8";
}

# Every page points to the llms.txt that covers it (llms.txt v2)
add_header Link '</docs/llms.txt>; rel="describedby"' always;

The Apache variant (for a VirtualHost or .htaccess) sets AddType text/markdown .md and AddCharset utf-8 .txt .md and uses mod_headers to append the header Link: </docs/llms.txt>; rel="describedby" to every response. The HTML variant gives you the two <link> elements for the <head>: rel="describedby" pointing to the llms.txt for every page it covers, and rel="alternate" type="text/markdown" pointing to a page's Markdown version.

Open File and automatic saving

Open File opens an existing file (.txt or .md, up to 5 MB); alternatively, simply drop it onto the form column. The tool reads it in the browser, parses it, and fills the form — title, summary, details, sections, links, subsections, and an llms-full.txt link from ## Optional.

Loading is lossless except for the name of the llms-full.txt link (see below): whatever the form can't represent as a field ends up as text in the details or the section text instead of being dropped. A byte-order mark at the start is removed. If the tool had to adjust anything, a notice "Loaded … — adjusted to fit the form" appears above the form, listing the adjustments with line numbers (the first five per message, then "and N more"), for example:

• lines before the H1 move into the details;
• headings in the details are escaped (\#);
• text under an H3 subsection moves into the section text;
• lines in sections that aren't links are kept as section text (output before the links);
• notes after a link now start with : (a separator such as - is replaced);
• the list bullets * and + become -;
• indented, nested list items become regular links.

A few normalizations happen silently, without a mention in the notice: a multi-line summary is joined into one line, runs of whitespace in link names and notes collapse to a single space, and the llms-full.txt link — recognized on load by the name llms-full.txt or by a URL containing llms-full — is always written as llms-full.txt (a custom link name is lost) and placed after the other direct links of an existing ## Optional section, or in a new ## Optional section at the end of the file; without a note of its own, it gets the default text "The complete documentation in one file".

Independently, the generator saves your work in progress locally in the browser (LocalStorage) on every change — close the tab and come back, and your work is still there. Reset clears that store.

The Check tab: validate live

The Check tab fetches an existing llms.txt from any domain and checks it against the llmstxt.org (opens in a new tab) specification. Possible inputs:

• a domain (e.g. example.com) — /llms.txt is appended automatically;
• a directory with a trailing slash (e.g. example.com/docs/) — the tool checks /docs/llms.txt;
• a full URL.

If the scheme is missing, the tool adds https://. By default the fetch goes through the server-side proxy. Optionally there's an Expert Mode (toggle in the page header) that fetches the file via a self-run local proxy at http://127.0.0.1:<port> — advanced and not needed for normal use.

What the validator checks

Validation runs client-side in your browser and checks structure and format against spec v2. Content inside code blocks (``` or ~~~) never counts as structure. Messages of the same kind are merged into one line with the affected line numbers attached (the first five, then "and N more"). The result is organized into three levels:

• Errors (red) — violations of what the spec requires:
  • empty file;
  • content before the H1 — the file must start with # Name;
  • missing H1 heading, or an H1 that is present but empty;
  • a link with an empty URL.
• Warnings (yellow, should be fixed):
  • no blockquote summary after the H1 (optional, but it's what agents read first), or a blockquote that doesn't directly follow the H1;
  • headings in the details before the first H2;
  • more than one H1; an empty H2; the same section name used twice (parsers that index sections by name keep only the last one);
  • a list item without a link — every item in a link list needs [name](url);
  • a list bullet other than - (the reference parser only reads -);
  • a link with an empty name;
  • a relative URL — agents may read the file detached from its location, so absolute URLs are needed;
  • a note after a link without : as the separator;
  • a link the reference parser reads differently (] in the name, ( ) in the URL — encode them as %28 %29);
  • a code block that is never closed;
  • no ## sections, or no links;
  • a large file over 50,000 bytes — the detail belongs in the linked pages.
• Info (notes):
  • running text in a link section, or H3 subsections — not part of the spec, no problem for agents;
  • a link using http:// instead of https://;
  • "N of M links have no notes" — a short note helps agents choose;
  • a section named "Optional" — since v2 a convention without special processing;
  • a byte-order mark at the start — allowed since v2;
  • a very short file (under 100 bytes);
  • the Python reference parser can't read the file, with the reason (e.g. no text between the H1 and the first section, or lines in sections that aren't links) — this only matters for that tool;
  • the success message: "Structure follows the llms.txt specification" when there are no errors, no warnings, and no deviations, or "No errors or warnings — minor deviations from the spec are listed as notes" when only section text or H3 subsections stand out.

In short: an H1 at the top and no empty link URLs are strictly required (errors). A summary, sections, clean link syntax, and absolute URLs are strongly recommended (warnings); notes and https:// are polish (info).

What the check tests in the HTTP response

Before the content is validated, the Check tab assesses the server's response itself. These messages appear in the same lists:

• Error: the server returns an HTML page (content type text/html, or content starting with <!doctype html or <html) — usually there's no llms.txt at all, and you're looking at an error or start page.
• Warning: a content type other than text/plain or text/markdown.
• Warning: a content type without charset=utf-8 although the file contains non-ASCII characters — browsers and some clients then display those characters wrongly.
• Warning: the file is not valid UTF-8.
• Warning: the file is larger than 1 MB — only the first megabyte was checked.
• Info: the request was redirected ("Redirected to …").

If the address returns HTTP 404 or another status outside 2xx, the tool reports "No llms.txt at … (HTTP nnn)"; an empty response is reported as "returned an empty file", and a failed fetch with its error message.

Reading the check result

At the top is a status banner with the fetched URL, the HTTP status, the content type, and a verdict:

• green "No errors or warnings." — 0 errors and 0 warnings;
• yellow "N warning(s)." — no errors, but warnings;
• red "N error(s)." — at least one error.

Below it a Summary table:

Then come the Errors, Warnings, and Info lists (each with a count, shown only when non-empty), the Linked pages card (see below), and a collapsible Raw content block with line numbers. From there you can Copy the raw content or use Load into Generator to pull it into the form and repair the file — loading is just as lossless as with Open File; if the generator already has output, the tool asks first — thanks to the pre-filled "Documentation" section that's practically always the case unless you've cleared or removed it.

Link check: testing the linked pages

If the file contains links, the Linked pages card shows a button Check all N links — or, with more than 20 links, Check the first 20 of N links. The link check runs on demand, one link after another with a short pause in between. Relative URLs are resolved against the (possibly redirected) address of the llms.txt. For each link the proxy only asks for the status and content type (with a HEAD request; if the server rejects HEAD, with a small GET). The table shows the number, link, status, type, and an assessment:

• OK or Redirect → target — reachable and not HTML (e.g. Markdown or text);
• HTML page — a markdown version (.md) is easier for agents — reachable, but an HTML page;
• Broken link — status 400 or higher;
• Not an http(s) URL or No response — not testable, or no answer.

A closing line sums up how many links are Markdown/text, HTML, or broken/unreachable.

Format reference

The Reference tab holds the v2 specification the generator produces and the checker validates: Markdown at /llms.txt or a subpath, in this order. The elements:

The complete example in the Reference tab (Complete Format) can be copied as a template with Copy. At the end of the tab, Further Reading links to the specification, the GitHub repository with its change log and the Python reference parser, three directories of websites with an llms.txt, the description of the Lighthouse audit, and two real-world example files.

llms-full.txt — the combined content file

llms-full.txt contains the merged text content of all pages linked in the llms.txt, in one large file. Useful for LLM clients that can process large context windows in a single request, want to avoid many individual HTTP requests, or need a cached/offline snapshot of your docs. The tool makes clear that llms-full.txt is a convention and not part of the llms.txt proposal. The recommended way to produce it is during your build, by concatenating the Markdown versions of the linked pages.

Markdown versions and discovery (v2)

The Reference tab sums up the v2 conventions that get agents to clean content:

• Pages agents may need get a Markdown version at the same URL: page.html.md (appended) or page.md (extension replaced); directories use index.html.md or index.md.
• rel="alternate" type="text/markdown" points from a page to its Markdown version.
• rel="describedby" points from a page to the llms.txt that covers it.
• Both work as a <link> in HTML or as an HTTP Link: header — the header also works for the Markdown files themselves.

Link: </docs/page.html.md>; rel="alternate"; type="text/markdown", </docs/llms.txt>; rel="describedby"

The generator produces the matching server snippets under Serving & discovery; you switch the link targets under Link targets: Markdown versions.

Limits, architecture, and privacy

• Generator: purely client-side. The file is assembled and checked entirely in your browser; a file opened via Open File is read by the browser itself, too. Nothing is transmitted. Your work in progress lives in LocalStorage.
• Check and link check: server-side proxy. Your browser can't fetch a third-party llms.txt directly because of CORS. A server-side JPKCom proxy retrieves it via cURL and returns the content, status, content type, and final URL; for the link check it only asks for status and content type. Validation then runs locally in your browser again. The checked domain sees the request from the JPKCom server (with its User-Agent), not your IP address.
• SSRF protection: the proxy blocks localhost, internal, private, and reserved IP addresses and re-validates every redirect hop; only HTTP and HTTPS are allowed. A local dev or intranet file can't be checked this way (that's what Expert Mode with a local proxy is for).
• Fetch limits: body cap 1 MB — larger files are truncated and only the first megabyte is checked (with a warning). Timeout 10 s per request, at most 30 s across all redirects, at most 5 redirect hops.
• Rate limits: in the browser, at least 3 seconds must pass between two checks (bypassed in Expert Mode); fire faster and the tool asks you to wait a moment. Server-side, the proxy accepts at most 120 requests per minute per IP address; beyond that the tool reports "Too many requests — please wait a minute". That's also why the link check tests at most 20 links per run.
• No public API: the two server-side endpoints (a fetch proxy and a token-based authentication endpoint) are used exclusively by the tool's own JavaScript and hardened against abuse — they're not meant to be called from the outside.

For the starting point and the big picture, see the overview page; for concrete walkthroughs the examples; and for strategy the tips & tricks. You can try all of it directly in the tool.