security.txt Checker – Complete Guide to RFC 9116 Security Contacts and Validation

A researcher finds a flaw in your web application and wants to report it responsibly. Without a published contact, the report ends up in a general support queue, a social media message, or nowhere. RFC 9116 solves this with one small file in a predictable place — but it is just as easy to publish a file that has expired, sits at the wrong path or writes the contact in a form readers cannot use.

The security.txt Checker looks for /.well-known/security.txt (then the legacy /security.txt) on a site, or takes pasted content, and validates it against RFC 9116: required fields, URI schemes, the Expires date, the location, the content type, the Canonical field and signature detection. A valid result means the contact details are published correctly — nothing more.

What is security.txt?

In simple terms

security.txt is the “who to call about security problems” sign for a website. It is a short text file with lines such as Contact: mailto:[email protected] and Expires: 2027-06-30T23:00:00Z, published at a fixed address so that anyone who finds a vulnerability knows where to send it and can tell whether the information is still current.

Technical background

RFC 9116 (2022) defines the format and location:

• Location. The file must be at /.well-known/security.txt (a well-known URI registered with IANA, see RFC 8615), served over HTTPS with media type text/plain. A copy at /security.txt is legacy and may redirect to the well-known path.
• Syntax. Each line is Field: value; field names are case-insensitive, and lines starting with # are comments.
• Required fields. Contact (one or more, in order of preference; a mailto:, tel: or https:// URI) and Expires (exactly once; an RFC 3339 date-time; recommended less than a year ahead).
• Optional fields. Encryption (a key location, e.g. https:// or openpgp4fpr:), Acknowledgments, Preferred-Languages (at most once; RFC 5646 language tags), Canonical (the URIs where the file is meant to be found), Policy and Hiring. Additional fields are registered with IANA, such as CSAF for security advisories. Web URIs must use HTTPS.
• Signing. The file may be signed as an OpenPGP cleartext signature; a signed file should list its Canonical location(s), so a copy cannot be replayed elsewhere.

Why use a security.txt checker?

• Expiry drift. Files are published once and forgotten; after the Expires date researchers should treat the contacts as stale.
• Wrong location or content type. A file only at /security.txt, or served as text/html, is not compliant.
• Formatting errors. Bare email addresses, http:// links, non-RFC 3339 dates and duplicated Expires lines are common.
• Soft 404s. Sites that return their normal HTML page for every URL look as if they have a security.txt when they do not.
• Canonical mismatches. After moving domains, the Canonical field often still names the old address.

Who should use it?

• Security and IT teams responsible for vulnerability disclosure.
• Web administrators and DevOps engineers deploying the file.
• Security researchers and bug bounty hunters looking for the right contact.
• Compliance and governance staff checking that a disclosure process is published.

How the security.txt checker works

Fetch mode. You enter a domain or any URL on the site. The checker takes the origin (assuming https:// when no scheme is given) and the NetTools.tech server requests /.well-known/security.txt; only if that does not yield a usable file does it try /security.txt. No other paths are requested. Each request goes through the SSRF-protected fetcher (public addresses only, ports 80, 443, 8080 and 8443, every redirect re-checked), follows up to 5 redirects, times out after 8 seconds and reads at most 64 KiB. A response counts as found only if it is a 2xx text response that is not HTML. The content and both attempts are returned to your browser and not stored.

Paste mode. The content is analyzed in your browser only. An optional File address enables the location checks (HTTPS, well-known path, Canonical match); the content type cannot be checked for pasted text.

Validation (in your browser):

1. HTML content is rejected as malformed. An OpenPGP cleartext signature is detected and its armour removed before parsing; the signature is not verified.
2. In fetch mode: the final URL must be HTTPS; a file found only at /security.txt gives a warning; the content type must be text/plain (error otherwise), ideally with charset=utf-8 (warning).
3. Each non-comment line must be Field: value; other lines are errors.
4. Contact: at least one, each a valid URI; http:// is an error, schemes other than mailto:, tel: and https: a warning, and a bare email address gets a “write mailto:…” hint.
5. Expires: required, exactly once, RFC 3339. Past dates make the status Expired; more than about a year ahead or less than 30 days away are warnings.
6. Encryption allows https:, openpgp4fpr: and dns:; Acknowledgments, Policy, Hiring, CSAF and Canonical must be https:. Preferred-Languages must appear at most once with valid language tags.
7. Canonical is compared with the URL where the file was found: a mismatch is a warning, or an error for signed files. Missing Canonical and Policy fields, and unknown fields, produce info notes.

How to use the NetTools.tech security.txt Checker

1. Open the security.txt Checker.
2. Choose Check a website and enter a Domain or URL, for example example.com; the hint shows which two URLs will be tried. Or choose Paste security.txt, paste the content and optionally enter the File address.
3. Load example (paste mode) fills in a complete sample file.
4. Press Check security.txt.
5. Read the status banner, the Fields table and Validation, then the Raw file with marked lines. Copy file copies the content.

Understanding the results

Example: the sample file

Load example fills in a file that starts with the comment line # Security contact for example.com (comments are ignored) and continues:

Contact: mailto:[email protected]
Contact: https://www.example.com/security/report
Expires: 2027-06-30T23:00:00.000Z
Encryption: https://www.example.com/.well-known/pgp-key.txt
Acknowledgments: https://www.example.com/security/hall-of-fame
Preferred-Languages: en, lv
Canonical: https://www.example.com/.well-known/security.txt
Policy: https://www.example.com/security/policy

Checked on 17 October 2026, this file is Valid: two contacts, a correctly formatted Expires about eight and a half months ahead, valid language tags and HTTPS links throughout. With the file address https://www.example.com/.well-known/security.txt, Validation also confirms the required location and that Canonical matches.

Now change a few lines to Contact: [email protected] and Expires: 30 June 2027. The status becomes Invalid: Contact must be a URI (with the hint to write mailto:[email protected]), and Expires is not an RFC 3339 date-time. If you instead publish the file only at https://example.com/security.txt, fetch mode reports the legacy-location warning, and the Canonical field — which names www.example.com/.well-known/… — no longer matches where the file was found.

Common use cases

• Verifying a new security.txt right after deployment.
• Adding the expiry date to a recurring review and checking it before it lapses.
• Auditing many company domains for a published, current contact.
• Finding the right reporting channel for a vulnerability you found on someone else’s site.
• Checking the HTTPS setup at the same time with the SSL Certificate Checker — the file must be served over HTTPS.

Troubleshooting

“Served as text/html; it must be text/plain”

The web server sends the wrong media type. Configure it to serve /.well-known/security.txt as text/plain; charset=utf-8. If the response is actually an HTML page, the file is not being served at all.

Not found, but the file exists

Static site generators and some hosting platforms skip directories starting with a dot, so /.well-known/ never gets deployed. Check the deployed output, and make sure no rewrite rule sends the path to the application.

“Found only at /security.txt”

Move the file to /.well-known/security.txt and, if you want to keep the root path, redirect it there. Use the Redirect Checker to confirm the redirect.

Canonical does not include the URL the file was found at

The comparison is exact, using the final URL after redirects. A host difference (www or not), http vs. https or a different path all count as mismatches. List every URL where the file is published.

Expires warnings right after publishing

Expires is more than a year ahead. RFC 9116 recommends less than a year so the file is reviewed regularly; pick a date within the next twelve months.

Common mistakes

• Writing email addresses without mailto:.
• Using local date formats or omitting the time zone in Expires.
• Repeating Expires, or Preferred-Languages, on several lines.
• Linking policy or key pages with http://.
• Signing the file but leaving out Canonical, or leaving an old domain in it.
• Treating a valid file as evidence of good security.

Limitations

• The checker validates format and location, not whether anyone reads the contact mailbox or answers reports.
• OpenPGP signatures are detected but not cryptographically verified; verify them yourself with the published key.
• Only the two standard paths on the origin you enter are checked; other hosts and subdomains need their own check.
• The content type can only be checked in fetch mode.
• The Canonical comparison is a strict string match against the final URL.
• Files larger than 64 KiB are truncated in fetch mode.
• It does not assess the security of the website itself — for that, see the Website Security Assessment.

Security & privacy

In fetch mode the domain is sent to the NetTools.tech server, which requests only the two security.txt paths on that host and returns the result to your browser; neither the domain nor the file is stored. In paste mode nothing leaves your browser. security.txt is a public file by design: publish role addresses such as security@ rather than personal ones, and never put credentials, internal hostnames or unpublished vulnerability details in it.

Related tools

• Robots.txt LLM Policy Checker — another well-known site file, for crawler policy. Guide: AI crawler policy guide.
• llms.txt Checker — validate the proposed llms.txt file. Guide: llms.txt Checker guide.
• SSL Certificate Checker — confirm the HTTPS setup the file depends on. Guide: SSL certificate guide.
• Redirect Checker — verify the redirect from /security.txt to the well-known path.
• Website Security Assessment — a separate, non-intrusive look at a site’s security posture. Guide: Website security assessment guide.
• Category overview: Security testing tools guide.

Summary

security.txt (RFC 9116) publishes how to report vulnerabilities: at least one Contact URI and exactly one Expires date, at /.well-known/security.txt, over HTTPS, as plain text. The security.txt Checker fetches or takes the file, validates every field, the expiry, the location and the Canonical URL, and marks the lines that need fixing. A valid file means the contact details are published correctly, not that the site is secure.