How to Check if a Website Has a security.txt File (RFC 9116)
To check if a website has a security.txt, open /.well-known/security.txt over HTTPS and look for a Contact line and one Expires line. The security.txt checker reads the file for up to 100 sites a run (500 after a free Google sign-in) against RFC 9116 and reports the contacts, the expiry date, days left and every rule broken.
It fetches one file per site. Nothing is sent to the contact addresses.
The by-hand way
- Open
https://yoursite.com/.well-known/security.txt. If nothing is there, try/security.txt, the legacy path. - Find at least one
Contact:line, amailto:,https://ortel:URI. - Find exactly one
Expires:line, a date-time such as2027-03-31T23:59:59Z. - Check any web links use
https://.
Easy to do once, easy to forget for a year. A file that was fine when published can expire and sit there with a stale contact.
Step 1: paste the sites
Paste one website or a list, one per line. Up to 100 a run without an account, 500 after a free Google sign-in.
Step 2: run the check
Each site's /.well-known/security.txt is fetched over HTTPS, then the legacy /security.txt if the first has no file. An HTML page served in place of the file, a common catch-all 404, counts as no file.
Step 3: read each verdict
| Verdict | What it means | What to do |
|---|---|---|
| Valid | Required fields present and Expires is in the future | Nothing to fix |
| Expired | The Expires date has passed | Update the date and review the contacts |
| Has errors | A rule is broken, such as a missing Expires or an http:// link |
Fix each listed error |
| No security.txt | No file found | Add one if you want vulnerability reports |
| Unreachable | The site did not answer | Try again later |
Sort the CSV by days left to find files about to expire.
What RFC 9116 asks for
Contact says how to report a vulnerability, and Expires limits how long the file is trusted. RFC 9116 recommends an expiry less than a year ahead so the file gets reviewed. Other fields, such as Encryption, Policy, Hiring and Canonical, are optional. See also reading a site's HTTP headers and the security headers checker for the response-side settings.
What this check cannot do
- It reads the file's format. It does not contact anyone or confirm a Contact address works.
- OpenPGP signatures are recognised but not verified.
- Only HTTPS is fetched, as the RFC requires. A file served only over HTTP counts as missing.
- The limit is 100 sites a run without an account and 500 signed in.
Check the security contacts you found
Before you email them, check the addresses. Upload the list on the verify page: the first 100 email checks are free with a Google sign-in, no card. Each address comes back valid, risky or invalid with a reason, and nothing is sent to anyone on the list. For larger or recurring lists, see bulk email verification, list cleaning and pricing.
Check your sites now
Paste them into the security.txt checker.
Common questions
How do I check if a website has a security.txt?
Open /.well-known/security.txt over HTTPS. A valid file has at least one Contact line and exactly one Expires line. A security.txt checker reads the file for many sites and reports each rule it breaks.
Where does security.txt go?
At /.well-known/security.txt. A copy at /security.txt is allowed for older tools, but when both exist the /.well-known one wins.
What fields are required?
Two: Contact, which may appear several times, and Expires, which must appear exactly once as an RFC 3339 date-time.
Why must it be served over HTTPS?
RFC 9116 requires it because a contact address is what an attacker would want to swap. Over plain HTTP, reports could be redirected.
Does the checker confirm the contact address works?
No. It reads the file's format only. It does not contact anyone.
Check your list before you send
Real mailbox checks over SMTP, and nothing is sent to the address. Sign in with Google and your first 100 email checks are free, no card. Plans for bigger lists are on the pricing page.