security.txt Validator
Check a security.txt the way researchers and scanners read it — every RFC 9116 rule, the expiry maths, the legacy-location trap — and get the corrected file back.
| Check | Result | Detail |
|---|
Corrected security.txt
File as fetched
How to Use security.txt Validator in 3 Steps
Fetch or paste
Enter the site — the tool fetches /.well-known/security.txt, the only location RFC 9116 defines, and also tries the legacy /security.txt to warn if that is the only copy. Or paste the file. Press Validate.
Read the checklist
Every rule in RFC 9116 gets a row: Contact present and a valid mailto:, https: or tel: URI; Expires present, in the future and less than a year away; Canonical matching where the file was served from; Policy, Acknowledgments, Hiring, Encryption on HTTPS; Preferred-Languages as BCP 47 tags and listed once; unknown fields; line endings; a PGP cleartext signature if present; and the content type the server used.
Publish the corrected file
Open Corrected security.txt — the same fields, normalised, with a fresh one-year Expires if yours is missing or stale — and upload it to /.well-known/security.txt, served as text/plain; charset=utf-8. If you sign it, re-sign after editing.
security.txt Validator — Frequently Asked Questions
What is security.txt and do I need one?
A small text file (RFC 9116, 2022) at /.well-known/security.txt that tells security researchers how to report a vulnerability to you. Scanners, bug-bounty platforms and government CERTs look for it; several national guidelines (NCSC-NL, CISA BOD 20-01) require it for public bodies. It takes two lines — Contact and Expires — to be valid.
Why must Expires be less than a year away?
The RFC recommends it: the field exists so stale contact details are noticed. Scanners and this tool flag an expiry more than 365 days out as a warning and a past date as an error (the file “must not be used” once expired). Set a calendar reminder and bump it yearly.
Is the legacy /security.txt location still valid?
No. Early drafts allowed the root, and the RFC says the root “may” be used only as a redirect to /.well-known/security.txt. If the tool finds a file only at the root, it reports a failure; if both exist and differ, it reports the mismatch.
Should I sign the file with PGP?
Optional but recommended when you publish an Encryption key: a cleartext signature (-----BEGIN PGP SIGNED MESSAGE-----) proves the contact details were not tampered with. The tool detects a signature and checks the Canonical field, which the RFC requires in signed files; it does not verify the signature itself.
What content type should the server send?
text/plain; charset=utf-8. The tool shows the content type it received; HTML (a CMS catching the path and serving a page) is the most common mistake and is reported as an error.
Why does fetching sometimes fail — and what is the relay?
Browsers block JavaScript from reading other websites directly (CORS). The tool first tries a direct request; when the site forbids it, the URL only is sent to a public read-only relay (allorigins.win, then codetabs.com) that fetches the page and returns its HTML. The relay sees the URL you typed, nothing else — Toolity has no server and keeps no record. If the relay is busy or the site blocks bots, paste the page source instead: that path is 100% local.
Is my input sent anywhere?
No. Everything is computed by JavaScript in your browser tab. Nothing is uploaded, logged or stored by Toolity.