security.txt Validator
Paste your security.txt (RFC 9116) content to detect syntax errors. Checks required fields like Contact and Expires and their value formats, so you can confirm it's correctly published at /.well-known/security.txt.
Validating the format of a security.txt
A security.txt is the text file by which a site tells anyone who has found a vulnerability where to get in touch, and its format is laid down in RFC 9116. Paste its contents in and this tool checks the syntax, confirming that required fields such as `Contact` and `Expires` are present and that their values take the right form.
**What tends to be overlooked here is the treatment of `Expires`.** Not only is it a required field, but **a file whose stated moment has passed is treated as no longer valid.** Publish one and leave it alone and, a few years later, it will be present yet inert, so it needs to be run with a plan for renewal. **Its location is fixed too: it belongs at `/.well-known/security.txt`.** Where the file is signed, the `Canonical` field states the authoritative URL so that readers can satisfy themselves the file has not been tampered with.
How to use it
- Paste in the contents of your security.txt Put in the whole file exactly as it stands.
- Try the samples first A valid example and one containing errors are both provided.
- Read the points raised **Missing required fields and malformed values are both reported.**
- Check the moment given in `Expires` **Confirm that it does not lie in the past, and decide in advance when you will renew it.**
Tips for getting more out of it
- The official location for security.txt is
/.well-known/security.txt. For compatibility, it's also worth publishing a copy at/security.txt(the site root). - Write Contact as a URI with a scheme, such as mailto:, https:, or tel:. A bare email address isn't RFC 9116-compliant and may not be recognized by automated parsers.
- Set Expires no more than a year out, and extend it each time you renew. An expired file risks being treated as an abandoned, unmonitored contact.
- All validation in this tool runs entirely in your browser — nothing you paste is sent anywhere, so it's safe to check a file before publishing it.
Where it comes in useful
Making your security contact explicit
A finder need not hunt around for an address, which makes a report far likelier to arrive.
Inspecting what you have published
**A malformed file gives no outward sign of trouble, so nothing short of validation will reveal it.**
Guarding against expiry
You can check at intervals that `Expires` has not lapsed.
Keeping a standard across an organisation
Where several sites are run together, you can confirm that all of them follow the same format.
Security.txt terms
- Contact
- A **required field** giving a means of getting in touch: an email address, a telephone number or the URL of a reporting form.
- Expires
- A **required field** after whose stated moment the file is treated as no longer valid.
- Encryption
- Points to a public key with which a report may be encrypted.
- Policy
- The URL of a page setting out the policy on vulnerability disclosure.
- Canonical
- The authoritative URL at which this file is meant to sit. **It is what a signature is checked against.**
- Preferred-Languages
- States the languages in which reports can be received, listed with commas as in `en, ja`.
Frequently Asked Questions
https://example.com/.well-known/security.txt as the official location. Many implementations also check the legacy path https://example.com/security.txt, so publishing it in both places is recommended for compatibility.mailto:[email protected]. Without a scheme, automated parsers may fail to recognize it correctly.
Side Note — The origin of security.txt — the "first point of contact" that bug bounties alone couldn't provide
security.txt was proposed in 2017 by security researchers Ed Overflow and Kagan Baytas. At the time, researchers who found a vulnerability often had no clear way to report it, ending up stuck with a general contact form or a direct message on social media. Reports frequently took a long time to reach the right person, or were simply ignored.
The proposal was brought to the IETF (Internet Engineering Task Force), and after years of discussion and revision it became an official standard as RFC 9116 in 2022. The mechanism is simple: a site operator publishes a single text file at /.well-known/security.txt, and researchers can mechanically determine who to contact, in what language, and under what policy.
Major tech companies including GitHub, Google, Facebook, and LinkedIn have all adopted security.txt, and it's common to see a link to a vulnerability disclosure or bug bounty program surfaced via the Policy field. It effectively serves as a "front door" reaching researchers who might never discover a bug bounty platform on their own.
As a natural extension of RFC 9116, a growing number of organizations link to CSAF (Common Security Advisory Framework) documents via the CSAF field, standardizing how vulnerability advisories are exchanged. security.txt is no longer just a contact file — it continues to evolve into an entry point for an organization's entire security response process.