RFC 9116 Compliance Checker
Enter a URL, domain, or paste your security.txt content to validate it against the RFC 9116 standard. Read the full guide.
security.txt is a proposed internet standard (RFC 9116) that gives websites a simple, machine readable way to publish vulnerability disclosure information. By placing a plain text file at /.well-known/security.txt, organizations tell security researchers exactly how to report issues. Without it, researchers are left guessing where to send reports, which can delay critical fixes or lead to public disclosure before the issue is resolved.
When a researcher discovers a vulnerability on your site, the first thing they need is a way to reach you securely. Generic contact forms and support emails often go to the wrong team or get lost in ticket queues. A security.txt file provides a direct, trusted channel. It also signals that your organization takes security seriously, which builds confidence with researchers, partners, and customers alike.
A security.txt file is a standard (RFC 9116) that websites use to tell security researchers how to report vulnerabilities. It includes contact information, encryption keys, and disclosure policies. Think of it as a "if you find something broken, here is who to tell" sign for your website.
The file should be placed at /.well-known/security.txt on your web server. For example, if your site is example.com, the file should be accessible at https://example.com/.well-known/security.txt. Some sites also place it at the root path /security.txt as a fallback, but the .well-known location is the standard.
RFC 9116 requires two fields: Contact (at least one, telling researchers how to reach you) and Expires (a date after which the file should be considered stale). All other fields like Encryption, Policy, Acknowledgments, Canonical, Hiring, and Preferred Languages are optional but recommended where applicable.
The Expires field sets a date after which the information in the file should not be trusted. If your file shows as expired, update the Expires field to a future date (typically one year out). This ensures researchers know your contact information is still current. An expired file is treated as unreliable by automated tools.
Signing your security.txt with PGP is recommended but not required. A PGP signature proves the file was published by someone who controls the associated private key, which helps researchers verify they are reading the authentic file and not a modified version. If you have a PGP key, signing adds an extra layer of trust.
Yes. This validator supports three input modes: enter a URL or domain to fetch and validate a live file, or paste your security.txt content directly into the text box to validate it before deploying. This is useful for checking your file locally before pushing it to production.
We track security.txt adoption across the top 500 websites. Browse the index to see which major sites have published a security.txt and which are still missing one.