Security.txt checker that quotes the rule behind every finding

01Check a security.txt file

One shape goes in the box: the file contents, comments included. Field lines are read as Name: value pairs, one per line, as the grammar in RFC 9116 section 4 defines them. Lines starting with a hash are comments and are skipped.

In paste mode, findings describe the pasted text only. They do not establish that the file is served at /.well-known/security.txt. RFC 9116 section 3 says that for web-based services, organizations MUST place the file under the "/.well-known/" path.

02Every rule the checker applies, and the line it comes from

The checker reads the file with a line parser and applies the rules below. Each finding names the rule and prints the sentence from RFC 9116, from the IANA registry or from CSAF Version 2.0 that it uses.

• MUSTContact is required. Section 2.5.3: This field MUST always be present in a "security.txt" file. A file without a Contact line is reported as missing the required field.
• MUSTExpires is required and single. Section 2.5.5: This field MUST always be present and MUST NOT appear more than once. An absent, duplicated or unparseable Expires is reported, and a timestamp in the past is reported as a stale file.
• SINGLEThree fields appear at most once. Section 2: Unless otherwise indicated in a definition of a particular field, a field MAY appear multiple times. Expires (section 2.5.5) and Preferred-Languages (section 2.5.8) MUST NOT appear more than once. The IANA registry lists Bug-Bounty with Multiple Appearances "no". A second line of one of these three fields is reported. A repeated Contact, Policy, Encryption or other field is accepted.
• SCHEMEWeb links begin with https://. Sections 2.5.1, 2.5.2, 2.5.3, 2.5.4, 2.5.6 and 2.5.7: If this field indicates a web URI, then it MUST begin with "https://". The checker reports each http:// value of Acknowledgments, Canonical, Contact, Encryption, Hiring and Policy. Section 2.5.3 says that "mailto" and "tel" URI schemes must be used when specifying email addresses and telephone numbers, so a Contact value with no scheme is reported. CSAF Version 2.0 section 7.1.8 gives the same rule for the CSAF field, so an http:// CSAF value is reported too.
• KNOWNField names are the ones the standard defines. Section 2.5 defines Contact, Expires, Acknowledgments, Canonical, Encryption, Hiring, Policy and Preferred-Languages. The IANA security.txt Fields registry (Last Updated 2026-03-07) adds CSAF and Bug-Bounty. A field that is not in the registry is shown as ignored by readers, because section 2.4 says researchers MUST ignore any fields they do not explicitly support. It is not an error.
• FORMATEach line is a field, a comment or blank. Section 2 says that a field MUST always consist of a name and a value. A line that is not a "Name: value" field, or a field with no value, is reported. Section 4 says that the file format MUST be plain text, so text that starts with "<" is reported as an HTML page.
• VALUESome values are fixed. Section 2.5.8 says of Preferred-Languages that at least one value MUST be listed, so a Preferred-Languages line with no language tag is reported. Section 2.5.4 says the Encryption value MUST be a URI, so a value with no URI scheme is reported. The grammar in section 4 gives the value of Acknowledgments, Canonical, Hiring and Policy as a URI, so a value of these fields with no URI scheme is reported too. The IANA registry gives the lines "Bug-Bounty: True" and "Bug-Bounty: False", so another Bug-Bounty value gets a warning.
• URLURL mode checks how the file is served. Section 3 says that for web-based services, organizations MUST place the file under the "/.well-known/" path, that the file access MUST use the "https" scheme, and that the file MUST have a Content-Type of "text/plain" with the default charset parameter set to "utf-8". URL mode shows the HTTP status and the final URL after redirects, and reports a path other than /.well-known/security.txt, an http final URL and another Content-Type. Section 2.5.2 says that the contents SHOULD NOT be trusted when Canonical fields appear and none of them lists the URI used to retrieve the file, so URL mode warns in that case.

Section 2.5.5 says that the Expires value is formatted according to the Internet profiles of ISO 8601 as defined in RFC 3339. The checker accepts only the RFC 3339 date-time form, such as 2027-04-01T00:00:00Z. RFC 3339 says that the "T" and "Z" characters in this syntax may alternatively be lower case "t" or "z" respectively, so 2021-12-31T18:37:07z is accepted. The checker shows the days from now to Expires in UTC, reports a past date, and warns when the date is more than one year ahead, because section 2.5.5 makes that limit RECOMMENDED.

03What a check looks like

Paste this example and the checker reports the stale date:

Contact: mailto:security@example.com
Expires: 2020-01-01T00:00:00.000Z
Preferred-Languages: en

Expected findings: Contact present, Expires parses but is in the past so the file reads as stale, no duplicates, no unknown fields. Every press of Check the file recomputes the result from the text in the box at that moment; nothing is cached and nothing is sent anywhere.

Read before acting on any verdict above

04What this checker cannot tell you

The tool answers one narrow question, whether a security.txt file follows the rules listed in section 02 of this page. It does not answer any of these.

• LIMITPaste mode fetches nothing. It reads only the text you paste, so it cannot confirm that the file is reachable at https://your-domain/.well-known/security.txt, that it is served over HTTPS, or that redirects behave. URL mode checks these points. URL mode works only on this page at aiwebsitepipeline.com, because the fetch service lets only pages on aiwebsitepipeline.com read its answer.
• LIMITOnly the OpenPGP cleartext form is read. If the text begins with -----BEGIN PGP SIGNED MESSAGE-----, the checker reads the fields between that marker and -----BEGIN PGP SIGNATURE----- and shows a SIGNED row. The signature is not verified.
• LIMITURL mode sends the URL you type to the fetch service of this site, which reads the file and returns it. The service fetches https URLs on public host names. It refuses IP addresses and private or local host names, so for those URL mode shows FETCH FAILED with the reason that the service gives. Only pages on aiwebsitepipeline.com can read its answer, so a copy of this page on another address shows FETCH FAILED. If the service returns only the first part of a long file, the result says so.
• LIMITURIs inside the file are not resolved in either mode. A Contact, Policy, Encryption or Canonical value that points at a dead page is checked by scheme only.
• LIMITThe checker reports what the standard says about the file. It says nothing about whether a researcher ever contacted you, and it cannot tell you that from your side.

05Where these rules come from

The rules come from RFC 9116, the security.txt specification, published April 2022, and from the sources named below. The eight field names are read from its section 2.5, the location and Content-Type rules from section 3, and the grammar from section 4. CSAF, Bug-Bounty and the Bug-Bounty values come from the IANA security.txt Fields registry (Last Updated 2026-03-07). The lower case "t" and "z" rule comes from RFC 3339. The community page at securitytxt.org describes the same well-known location requirement. Each quoted sentence above is copied from the RFC 9116, RFC 3339 or IANA text fetched on 2026-10-29. The CSAF https rule is quoted from section 7.1.8 of CSAF Version 2.0, fetched on the same day.