BYTETOOLS

security.txt Generator

Build a valid RFC 9116 security.txt with Contact and Expires fields, URI validation and the optional Policy, Encryption and Canonical directives.

Contact (required, one per line)

Put the address you most want used first. Every value must be a URI: mailto:, https:// or tel:.

3
Fields written
0
Errors
364 days
Valid for

security.txt

# security.txt — RFC 9116
# Serve at https://example.com/.well-known/security.txt with Content-Type: text/plain; charset=utf-8
Contact: mailto:security@example.com
Expires: 2027-08-23T23:59:59Z
Preferred-Languages: en

Where to put it

  • /.well-known/security.txt — the canonical location. Serve it over HTTPS with Content-Type: text/plain; charset=utf-8.
  • /security.txt — the legacy fallback. RFC 9116 keeps it for compatibility, but scanners check the well-known path first.
  • Signing the file with PGP is optional. If you do, publish the detached signature at /.well-known/security.txt.sig and point Encryption at the key that made it.

What is the security.txt Generator?

security.txt is a plain-text file at /.well-known/security.txt that tells security researchers how to report a vulnerability to you. RFC 9116 requires a Contact field and an Expires field; everything else is optional.

  • Required Contact and Expires fields with live URI and date validation
  • Unlimited Contact lines, one per line as the RFC requires
  • Optional Encryption, Policy, Acknowledgments, Canonical, Hiring and CSAF fields
  • Warnings for expiry dates in the past or more than a year away
  • Copy or download the finished security.txt file
  • Deployment notes for both the well-known and legacy paths

How to use the security.txt Generator

  1. 1

    Enter at least one Contact URI, such as mailto:security@example.com, and add more lines if you have them.

  2. 2

    Pick an Expires date — under a year out is the recommendation.

  3. 3

    Fill in any optional fields that apply: Policy, Encryption, Acknowledgments, Canonical, Hiring, Preferred-Languages or CSAF.

  4. 4

    Fix anything flagged as an error, and read the warnings.

  5. 5

    Copy the generated file or download it, then publish it at /.well-known/security.txt.

About the security.txt Generator

If someone finds a vulnerability in your site, how do they tell you? security.txt is the standard answer: a plain-text file at a well-known path listing where to send reports, what your disclosure policy is, and when the file itself expires. This generator builds one that conforms to RFC 9116.

It enforces the rules that catch people out. Contact values must be URIs — mailto:, https:// or tel:, never a bare email address. Expires is mandatory and must be a real ISO 8601 timestamp, and the tool warns when it is more than a year out or already in the past. Optional fields are validated for scheme too, so Encryption cannot accidentally hold a pasted PGP key block.

Add as many Contact lines as you need, fill in whichever optional fields apply, and copy or download the finished file when the validation panel is clear. The tool also shows both paths you can publish to and explains when a PGP signature is worth adding. Everything is generated in your browser as you type — nothing is uploaded and no account is needed.

Frequently asked questions

What is a security.txt file?

It is a plain-text file at /.well-known/security.txt that tells security researchers how to report vulnerabilities to your organisation. It was standardised as RFC 9116 in 2022 and is now checked automatically by many scanners and bug bounty platforms.

Where should I put my security.txt file?

At https://yourdomain.com/.well-known/security.txt, served over HTTPS with Content-Type text/plain; charset=utf-8. The legacy path /security.txt still works as a fallback, but scanners check the well-known location first.

Why does security.txt require an Expires field?

So a stale file cannot mislead a researcher into emailing an address nobody reads any more. RFC 9116 makes it mandatory and recommends less than a year, which forces a periodic review of whether the contact details still work.

Can I use a plain email address in the Contact field?

No — it must be a URI, so write mailto:security@example.com rather than security@example.com. Parsers reject the bare form. You can also use an https:// URL pointing at a report form, or a tel: number.

Do I need to sign my security.txt with PGP?

It is optional. If you do, publish the detached signature at /.well-known/security.txt.sig and point the Encryption field at the key that made it. Most organisations publish an unsigned file, which is perfectly acceptable.

Related tools