Generators

Security.txt Generator

RFC 9116

Generate Your security.txt

Fill in your contact channels and disclosure details to generate a valid RFC 9116 security.txt, ready to publish at /.well-known/security.txt.
Configuration
ContactRequired
Email addresses become mailto: links automatically. The first contact is the preferred channel.
ExpiresRequired
After this date the file is considered stale and must be re-issued. RFC 9116 recommends less than a year.
Preferred languages
Encryption keyoptional
Acknowledgmentsoptional
Security policyoptional
Hiringoptional
Canonical URLoptional
Nothing generated yet

Fill in your contact channels above, then click Generate security.txt.

Tool features

Everything you need to publish a valid security.txt
4 features

Valid Contact URIs

Email addresses become mailto: links automatically, as RFC 9116 requires

Sane Expiry Dates

One-click expiry presets with a warning when you exceed the recommended year

Every Optional Field

Encryption, Acknowledgments, Policy, Hiring, and Canonical — all supported

Deploy Checklist

Copy or download the file with clear steps to publish and maintain it

What is security.txt & how it works

How researchers find where to report a vulnerability

security.txt (RFC 9116) is a small text file published at /.well-known/security.txt that tells security researchers how to report a vulnerability in your site or service. Without it, people who find a problem often cannot reach the right team, or give up.

The file needs at least one Contact and exactly one Expires field, and can add an encryption key, acknowledgments page, preferred languages, canonical URL, policy and hiring links. It should be served over HTTPS and refreshed before it expires, and can be cleartext-signed with PGP.

Contact
A mailto:, https: or tel: URI where reports should go; required.
Expires
An ISO 8601 date after which the file is stale; required, under a year ahead.
Canonical
The URL(s) where this file is officially published, to prevent spoofing.

How to use this tool

Create and publish security.txt in four steps
1
Add contacts
Enter at least one contact URI, e.g. mailto:security@example.com or an HTTPS reporting form.
2
Set the expiry
Choose an Expires date less than a year away and note it so you renew in time.
3
Fill optional fields
Add Encryption, Policy, Acknowledgments, Preferred-Languages, Canonical and Hiring as they apply.
4
Publish and validate
Serve the file at /.well-known/security.txt over HTTPS, then check it with the Security.txt Tester.

Frequently asked questions

Common questions about security.txt
5 Q&A

At https://example.com/.well-known/security.txt. A copy at /security.txt is allowed for legacy compatibility, but the .well-known path is the standard location.

RFC 9116 requires at least one Contact and exactly one Expires field. Everything else is optional.

The RFC recommends less than a year. A shorter window keeps the contact details fresh; set a reminder to update the file before the date passes.

It is optional. A PGP cleartext signature lets researchers verify the file has not been tampered with; if you sign it, include an Encryption field pointing to the public key.

No. It only tells people where to report. Use the Policy field to link to your disclosure policy and say whether you offer rewards.