security.txt generator and validator

What is security.txt?

A security.txt file is a short text file that tells anyone who has found a vulnerability in your site where to report it. Before it existed, a researcher who noticed something wrong had to guess: try security@ and hope it was monitored, hunt through a contact page, or give up and say nothing. The file replaces that guesswork with a fixed location and a small set of named fields, and it became a standard — RFC 9116 — in April 2022.

The format is deliberately plain. Each line is a field name, a colon, a space and a value, and lines starting with # are comments. Only two fields are required: Contact, which says where to send reports, and Expires, which says when the information should stop being trusted. Everything else — a link to your policy, an encryption key, a hall of fame, the languages you read — is optional.

It is also small enough to get wrong in ways nobody notices, which is what the checker on this page is for. Of the files published by the busiest 500 domains on the web, fewer than half currently satisfy the standard they are written to.

How to use it

1. Enter your contact and expiry. Contact must be a URI, so an email address needs a mailto: prefix and a phone number needs tel:. The expiry field is pre-filled a year ahead, which is the longest the standard recommends.
2. Add the optional fields you need. A policy link, an OpenPGP key, an acknowledgments page, the languages you read. Contact and most others may be listed more than once; Expires and Preferred-Languages may not.
3. Serve it, or check what you already serve. The file belongs at /.well-known/security.txt over HTTPS. Switch to the checking tab to paste an existing file and see every problem with its line number.

What most published files get wrong

The figures here come from fetching both possible locations for the busiest 500 domains on the web, ranked by Tranco, and running every file that came back through the same checker this page offers. 115 of those domains publish something; 45 of them, 39.1 per cent, have no errors at all.

The commonest defect by a wide margin is a missing Expires field: 48 files, 41.7 per cent of everything published. That is not an obscure rule — Expires is one of the only two fields the standard requires — and there is a clean reason for it. Expires did not exist in the early drafts everyone implemented from; it was added on the way to becoming an RFC. So the single most frequent problem is the field the standard added last, sitting in files that were correct when they were written.

Expiry has a second failure mode: 11 of these files declare that they have already expired, which by the standard's own definition means their contents should no longer be relied on. One large social network's file gave a date in January 2024. Thirteen more push the date so far out that it can never usefully lapse — one major search engine's says 2030, nearly four years away, against a recommendation to stay under one.

Fourteen files give a Contact that is not a URI. This is the trap the format sets for anyone typing what looks obvious: a bare address like psirt@example.com reads perfectly to a human and is invalid, because the field is specified as a URI and needs mailto: in front of it. One well-known software company publishes a correct https contact and then a bare address on the very next line. If you need to build one, our mailto link generator writes the whole thing.

Sixteen files contain a line that is not a field at all, usually a heading with spaces in it, and a handful are simply prose — a paragraph explaining how to report a bug, published at the path where a machine-readable file was expected. Six have no Contact field whatsoever, having invented their own names for it.

Where the file goes, and what it does not cover

The standard is specific about location: the file must be at /.well-known/security.txt. A copy at the root of the site is permitted only for legacy compatibility, and where both exist the well-known one wins. Twenty-six of the domains measured serve it at both, which is fine; eight serve it only at the root path, which means a tool following the standard may never look there.

The file's scope is narrower than most people assume. It applies only to the exact domain or IP address it was fetched from — not to subdomains, and not to parent domains. A file at example.com says nothing about anything.example.com, and each host that needs one needs its own.

Unknown fields are not errors. The standard tells readers to ignore any field they do not recognise, so the checker reports an unregistered name as a note rather than a problem. That is a deliberate choice on the standard's part, and a validator that flagged it as invalid would be contradicting the document it is validating against.

Two of the fields listed on this page appear nowhere in RFC 9116. IANA keeps the registry, and it has grown since publication: CSAF, which points at a machine-readable advisory feed and is the only field in the format whose change controller is not the IETF, and Bug-Bounty, which is the only one whose value is neither a URI, a date nor a language tag — it is simply True or False.

One thing this page does not do is verify signatures. A file may be wrapped in an OpenPGP signature, and eighteen of the ones measured are; the fields inside are checked normally, but confirming a signature would mean handling keys, which is a different job from reading a text format.

Why is it free?

The whole thing is a text format. Generating a file is string concatenation and checking one is a parser, both of which run in your browser, so there is no server to pay for and no account to create.

Nothing you type is uploaded, stored or logged. That matters more here than on most pages: a security contact file is public by design, but the draft you are still editing is not, and neither is the file you pasted in to find out what is wrong with it.