securitytxt.org is the reference
site for the format — it is where most people first meet security.txt, and it
offers a form that generates a file and a validator that checks one. If you do not have a
security.txt yet, start there: filling in a form is a better way to produce a first
file than reading an RFC.
This tool is aimed at a different moment. Not "help me write one", but "the one we wrote eighteen months ago — is it still doing anything?" Those turn out to want different shapes.
A generator is used once. Expires is a date, so conformance is not a one-time
state — which means the useful tool is the one you can put on a schedule and forget, rather
than the one you have to remember to revisit.
| securitytxt.org | This tool | |
|---|---|---|
| Main job | Generate a conforming file, and validate one interactively | Re-check a file you already publish, by hand or on a schedule |
| Interface | Web form | Web page and a zero-dependency Node CLI |
| Usable in CI | Not its purpose | Yes — exit code 1 on a must-fix finding |
| Fetches your live file | — | Yes: tries /.well-known/security.txt, then the legacy root copy |
| Checks the served location and media type | — | Yes, in CLI mode (a paste cannot show either) |
| Separates must-fix from worth-knowing | — | Yes: RFC MUSTs are dangers, SHOULDs and typos are notices |
| Runs without sending your file anywhere | — | Yes — browser-local, or your own machine via the CLI |
The dashes are "not what that tool is for", not "does it badly". The two columns are also not a live feature audit: this page describes securitytxt.org from its well-known role as the format's reference site rather than from a fetch made while writing it, and a site can change. Check it yourself before treating the row as current — and if it now does the thing you need, use it.
node check.mjs example.com # exit 1 once Expires has passed
Generate the file at securitytxt.org, publish it at
/.well-known/security.txt, then put node check.mjs yourdomain.com on a
monthly schedule so the expiry date stops being something you have to hold in your head. The
two tools are not really competing; they cover the start and the middle of the same job.
If you do not have a security.txt yet, start at securitytxt.org: filling in a form is a better way to produce a first file than reading an RFC. Come back here for the question that arrives later, which is whether the file you already published is still doing anything. The two cover the start and the middle of the same job, and using both is the sensible answer.
Because Expires is a date. A generator is used once, but RFC 9116 makes the expiry field mandatory and time-bound, so conformance is not a one-time state — which means the useful tool is the one you can put on a schedule and forget, rather than the one you have to remember to revisit.
When you are publishing for the first time, since a form that emits a correct file beats a checker that tells you the file you do not have is missing. When you want the canonical reading of the spec, since it is the format's own site and this is a third-party checker with no special authority. And when you want to sign the file interactively, since nothing here generates or signs keys — this tool only reads what you already have.
No. This page describes securitytxt.org from its well-known role as the format's reference site rather than from a fetch made while writing it, and a site can change. Check it yourself before treating any row as current — and if it now does the thing you need, use it.
Back to the tool: security.txt Checker. Background: why RFC 9116 made Expires mandatory.