security.txt Generator: RFC 9116 Maker with Validator
Security researchers need a working way to reach you when they find a flaw, and RFC 9116 defines the file that carries those contacts. A security.txt lives at /.well-known/security.txt on every origin, and scanners, bounty platforms, and human researchers all look for it there. This generator writes the required Contact and Expires lines plus the optional fields, then checks the result against the RFC rules. Paste any existing file into the parser panel to see what it reads.
Build and Check a security.txt File
Checks run in your browser when you press Generate.Press Generate to build the file.
Parser panel
Paste an existing file to list its fields, comments, unknown names, and issues.
How It Works
Two fields carry the file. Contact lists the URIs a reporter should use, one per line, and Expires is the last moment the file can be trusted. RFC 9116 allows mailto, https, and tel in Contact, while Policy, Hiring, Acknowledgments, and Canonical must be https URLs. Preferred-Languages takes tags such as en or en-GB.
When the Expires box is empty, the day selector supplies a date that far out, keeping the file inside the 90 to 365 day window most programs prefer. Issues appear above the output as a list: a missing Contact, a Contact URI that fails validation, an Expires date already past, or a window outside that range. Host the result at /.well-known/security.txt on each origin with Content-Type: text/plain and charset utf-8, since application/json is a mistake some crawlers reject.
Before and After: A Builder File and a Flagged Paste
The first sample is what the builder panel prints for a team with one mailbox, a dated expiry, and a policy page. The second shows a pasted file the parser flags, with the warning printed underneath.
Contact: mailto:security@example.com
Expires: 2027-06-01T00:00:00.000Z
Policy: https://example.com/security
Canonical: https://example.com/.well-known/security.txtContact: mailto:security@example.com
Expires: 2026-12-01
Policy: https://example.com/security
warning: Expires date-only; RFC 9116 examples use a full date-timeUse Cases
| Team | Situation | What to check |
|---|---|---|
| SaaS security page | A product domain goes live and researchers start probing it | The well-known file answering with a monitored Contact |
| Pentest delivery | An external tester finishes a scope and needs a disclosure path | Policy URL and a Contact that still reaches the on-call rotation |
| Compliance evidence | An auditor asks how vulnerability reports are received | Dated file with Expires inside the year and a Canonical line |
Common Mistakes
- Hosting the file only at the domain root. /security.txt is not the address scanners look for; the well-known path is required on every origin.
- Setting Expires years ahead and never renewing. Nobody revisits the contacts, and stale addresses bounce when a real report lands.
- Listing an https Contact that returns 404. Researchers give up on a dead link and file publicly instead.
- Serving the file with Content-Type: application/json. RFC 9116 section 2.3 asks for text/plain with charset utf-8.
- Putting a comment after a field value on the same line. The trailing text then travels as part of the value.
- Adding extension fields that reuse standard names. Extension names are lowercase letters, digits, and hyphens only.
Best Practices
- Renew before the file expires and keep the window between 90 and 365 days.
- Keep every Contact line reachable by someone who answers within a day during disclosure.
- Link Policy to a page that states scope, safe harbor, and response times.
- List one Canonical line per origin, each pointing at /.well-known/security.txt.
- Run the parser after every edit so a mistyped field name is caught before the next crawl.
- Add Preferred-Languages when the team answers in more than one language.
Frequently Asked Questions
What is security.txt and who reads it?
security.txt is a plain text file at /.well-known/security.txt that tells researchers how to reach you. RFC 9116 defines the format, and scanners and bounty platforms fetch it before filing. Without one, a finder guesses an email address or goes public.
Which fields are mandatory?
Contact and Expires are the two fields RFC 9116 requires. Contact carries at least one URI where a reporter can reach you, and Expires tells crawlers when to stop trusting the file. Policy, Hiring, Canonical, and Preferred-Languages are optional.
What URI schemes can Contact use?
RFC 9116 allows three schemes in a Contact line: mailto, https, and tel. A mailto value must be a plain email address, an https value a working URL, and a tel value a full phone number. The builder checks each line and reports why one fails.
How long should the Expires date be set for?
A window between 90 and 365 days is what most teams settle on. Too short and the file expires between renewals; too long and contact details go stale. The day selector fills the Expires box when you leave it empty.
Where do I host the file and with which Content-Type?
Serve the file at /.well-known/security.txt on every origin, including subdomains with their own certificate. RFC 9116 section 2.3 asks for Content-Type: text/plain with charset utf-8, not application/json. Return a plain 200 with no redirect or content negotiation.
Can the parser panel check a live security.txt?
Fetch the live file in your browser, paste the text into the parser box, and press Parse. The panel lists recognized fields, repeats comment lines, flags names outside the standard set, and runs the same checks as the builder. Nothing leaves the page.
Does this tool store or transmit my file?
No. Building, parsing, copying, and downloading all run inside the page with no network request carrying your data. Contact addresses and policy URLs stay in browser memory only, and closing the tab clears both panels.