What is a security.txt file for?

It gives people who find a security problem on your site one place to look for who to tell and how. Without it they may guess an address, post publicly, or give up. It is a standard (RFC 9116), and it takes a few minutes to write.

Where do I put the file?

Serve it at https://your-domain/.well-known/security.txt over HTTPS as plain text in UTF-8 (Content-Type: text/plain; charset=utf-8). A copy at /security.txt is allowed for older setups, but if both exist the /.well-known/ one is used. The file covers only the exact domain that serves it.

Which fields are required?

Two: Contact, which can appear several times with your preferred method first, and Expires, which must appear exactly once. Everything else is optional: Encryption, Acknowledgments, Preferred-Languages, Canonical, Policy and Hiring.

How far ahead should Expires be?

Less than a year. The RFC recommends this so contact details do not go stale. A common habit is to set it about a year ahead and renew it a month or so before it runs out. This page suggests one year ahead minus a day.

Do I have to sign the file?

No. Signing with an OpenPGP cleartext signature is recommended, and then the Canonical field should list the address the file is served from. Many sites publish an unsigned file, which is still valid.

Can I use http: links or a plain email address?

Web links in these fields must start with https://. An email address must be written as a mailto: link and a phone number as a tel: link, for example mailto:security@example.com. The form adds those prefixes when you type a plain address or number.

← All tools

Free tool for website owners and developers

security.txt generator and checker

A security.txt is a small text file at /.well-known/security.txt that tells researchers how to report a security problem to you. It needs a Contact line and an Expires date. Fill in the form to get the file, or paste yours to see what is missing, expired or misspelled. Everything happens in your browser.

Contact (required), one per lineAn email address, a phone number with country code, or an https:// link. Put the one you prefer first. Emails get mailto: and phone numbers get tel: added for you.Expires (required)The date after which readers should treat the file as out of date. Under a year ahead is recommended. The time is set to the end of that day, UTC.EncryptionA link to your public encryption key, never the key itself.AcknowledgmentsA page thanking the people who reported problems.Preferred languagesLanguage codes separated by commas, such as en, zh.CanonicalThe address this file is served from. Useful if you sign the file.PolicyA link to your disclosure policy.HiringA link to security job openings.

Your security.txt

Fill in a contact and an expiry date to see the file here.

Where to put it

•Serve it at https://your-domain/.well-known/security.txt. A copy at /security.txt is only for older setups; if both exist, readers use the /.well-known/ one.
•It must be reached over HTTPS and sent as Content-Type: text/plain; charset=utf-8.
•It covers only the exact domain it is served from, not its subdomains. Put one on each host that needs it.
•Set a reminder to renew it before the Expires date. An expired file is treated as out of date.

Optional: sign it

The RFC recommends signing the file with an OpenPGP cleartext signature, for example gpg --clearsign security.txt, and adding the Canonical field so the signature also vouches for the address. This page does not sign files; it only recognises a signed file when you check one.

How it works

•To write a file, add at least one contact and an expiry date. The other fields are optional. The page builds the text as you type; download it or copy it, then upload it to your site at /.well-known/security.txt.
•To check a file, paste its text. Each field is read line by line and compared with RFC 9116, and every finding names the line and the RFC section behind it.
•Errors break a rule the RFC states as a must, such as a missing Contact or Expires, an expired date, or an http: link. Warnings are things that probably do not work as intended, such as a misspelled field name. Notes are only information.
•Rules were checked against RFC 9116 on 2026-11-01. Nothing you type or paste leaves this page.

What it does and what it does not do

•It writes and checks the text of the file. It does not fetch your live file, so it cannot tell you whether your server sends it over HTTPS with the right Content-Type.
•It does not sign files or verify signatures. A signed file is recognised, and its text is checked, but the signature itself is not.
•It cannot tell whether your email address, phone number or links work, or whether the encryption key is the right one.
•Names it does not know are allowed by the RFC; they are listed as notes unless they look like a misspelling of a known field.
•Expires is set to the end of the chosen day in UTC. If you need another time or zone, edit the line afterwards.

Questions

What is a security.txt file for?: It gives people who find a security problem on your site one place to look for who to tell and how. Without it they may guess an address, post publicly, or give up. It is a standard (RFC 9116), and it takes a few minutes to write.
Where do I put the file?: Serve it at https://your-domain/.well-known/security.txt over HTTPS as plain text in UTF-8 (Content-Type: text/plain; charset=utf-8). A copy at /security.txt is allowed for older setups, but if both exist the /.well-known/ one is used. The file covers only the exact domain that serves it.
Which fields are required?: Two: Contact, which can appear several times with your preferred method first, and Expires, which must appear exactly once. Everything else is optional: Encryption, Acknowledgments, Preferred-Languages, Canonical, Policy and Hiring.
How far ahead should Expires be?: Less than a year. The RFC recommends this so contact details do not go stale. A common habit is to set it about a year ahead and renew it a month or so before it runs out. This page suggests one year ahead minus a day.
Do I have to sign the file?: No. Signing with an OpenPGP cleartext signature is recommended, and then the Canonical field should list the address the file is served from. Many sites publish an unsigned file, which is still valid.
Can I use http: links or a plain email address?: Web links in these fields must start with https://. An email address must be written as a mailto: link and a phone number as a tel: link, for example mailto:security@example.com. The form adds those prefixes when you type a plain address or number.