security.txt Generator
Build a valid /.well-known/security.txt file (RFC 9116) from a short form.
Results are provided as is, for general information. Check anything important before relying on it. See the Terms of Use.
About this tool
security.txt (RFC 9116) is the IETF standard that gives security researchers a machine-readable way to find the right person or team to report a vulnerability to — the web's equivalent of /security for Responsible Disclosure. The file is plain text with simple Field: value lines, hosted at a fixed well-known path on every domain. This tool builds it from a short form: the required Contact and Expires fields, plus the optional Encryption, Preferred-Languages, Canonical, Policy, Hiring and CSAF fields, each validated as you type. It renders the canonical field order the RFC's examples use, normalizes bare email contacts to mailto: and date-only expiries to full timestamps, and flags every problem it finds — an unsupported contact scheme, a timestamp without a UTC designator, an expiry already in the past — before you publish the file. Generation runs entirely in your browser.
When to use it
Questions
What is security.txt?
A plain-text file defined by RFC 9116 that websites place at /.well-known/security.txt to tell security researchers where to send reports: a security contact address, optionally a disclosure policy, an encryption key, and a few other fields. It is how a stranger with a vulnerability can reach the right desk without guessing at security@, abuse@ or a form buried in your docs. Major organisations publish one; auditors and bug-bounty programs increasingly expect it.
Where does the file live?
At https://your-domain/.well-known/security.txt — the RFC-mandated primary path — with https://your-domain/security.txt on the root as a fallback for convenience. Only https is allowed, redirects are followed, and you should set the Canonical field to the exact URL you consider authoritative so a copy at either path can be verified. Serve it as text/plain; charset=utf-8, and keep it under 50 KiB for consumers that cap their fetches.
Which fields are required?
Exactly two: Contact and Expires. Contact must be a mailto: or https: URI — one per line, and you may list several. Expires is a timestamp in ISO 8601 format; everything else (Encryption, Preferred-Languages, Canonical, Policy, Hiring, CSAF) is optional. The RFC recommends Expires be no more than a year out, so the file gets reviewed and stays current — a stale contact address is as bad as none.
Why does the file expire?
Because contact pages rot. Companies rebrand, security@ mailboxes go unmonitored, and researchers then report vulnerabilities into a void — sometimes to attackers when a domain lapses. A mandatory expiry forces the owning team to refresh the file and re-confirm the contact at least once a year. Consumers treat an expired file as no file at all, so mark your calendar; this tool warns when the date you pick is already in the past.
How do I publish the file I generated?
Download security.txt and host it at /.well-known/security.txt on every domain you want covered (including subdomains — the file does not inherit down the tree), served as text/plain; charset=utf-8 over https. If your web server can't easily add the path, a rewrite rule or a static-file route works; the fallback location /security.txt is allowed but the well-known path is what scanners check first. Once live, run it through an RFC 9116 checker and add the Canonical field pointing at the URL you published.