This page names no specific product or company: "checking it by eye" is reading a security.txt file yourself, a generic habit anyone with a text editor already has, not a competing tool.
Reading a security.txt file and eyeballing it for problems genuinely catches the case everyone pictures: a file with no Contact field at all, or one that is completely empty. That case is real, and it is not what this tool exists to replace. What it replaces is everything past that — a field whose value is wrong in a way that still reads as ordinary, complete text to a person scanning the file.
| Case | Checking it by eye | This checker |
|---|---|---|
Expires: 2025-06-01T00:00:00Z | Reads as an ordinary date sitting in a list of fields — nothing about its formatting changes whether it is next week or years past | Compares it against the actual current time and flags an expired file by name |
Contact: security@example.com | Reads as an obviously correct contact address — it is one | Flags it as not a URI: RFC 9116 requires the mailto: prefix specifically, so a parser can tell what kind of contact it is |
Acknowledgements: (British spelling) | Reads as a completely ordinary field name | Flags the misspelling by name and names the RFC-correct spelling, Acknowledgments |
Encryption: http://example.com/pgp-key.txt | An http vs. https difference of one letter, easy to skim past in a long URL | Flags plain-http explicitly |
Preferred-Languages: English | Reads as a perfectly reasonable value | Flags that "English" is not a valid language tag — RFC 9116 wants a tag like en |
Policy https://example.com/vulnerability-policy (no colon) | Still reads as a complete, sensible line — a field name followed by a URL | Flags it as a malformed field with the colon missing, since without it the line is not a field a parser can use at all |
Every case above shares the same shape: none of them looks broken. An expired date is still a date. A bare email address is still a contact. A misspelled field name is still a word. A missing colon still reads as a sentence. There is no red flag, no obviously wrong formatting — just a field whose meaning to a conforming parser differs from what it looks like to a person who already knows what the file is trying to say. This checker applies RFC 9116's own rules to every field, so a value that is wrong in a way invisible to a reader still gets flagged.
This is a conformance check, not a security review. It has no opinion on whether the contact address is actually monitored, whether the linked policy page is any good, or where the file is served from — a paste cannot show that, only the CLI checking a live URL can. Judging the substance behind the file is still a job for reading it.
It catches the case everyone tests: a file with no Contact field at all, or an obviously empty file. That is real, and it is not what this tool exists to replace. What it replaces is everything past that — a field whose value is wrong in a way that still reads as ordinary text.
A date sitting in a list of fields looks like a normal date whether it is next week or three years ago — nothing about its formatting changes when it is in the past. RFC 9116 says a consumer must treat an expired file's data as stale, so the file quietly stops doing its job while still looking complete to a person reading it. This checker compares the date against the actual current time and flags it by name.
security@example.com reads as an obviously correct contact address to a person — it is one. RFC 9116 requires Contact to be a URI specifically, so a conforming tool cannot tell whether that string is an email address, a username, or something else without the mailto: prefix. The distinction that matters to a parser is invisible to a reader who already knows what it means.
Acknowledgements (the British spelling, with the extra e) reads as a completely normal word. RFC 9116 spells the field Acknowledgments, without it, and a conforming parser silently ignores any field name it does not recognize — so the misspelled field, and whatever page it points to, simply never gets found by anything that reads the file correctly, with no error and no visual cue.
Policy https://example.com/vulnerability-policy without a colon after Policy still reads as a complete, sensible line — a field name followed by a URL. RFC 9116 requires the colon; without it, the line is not a field at all, just unstructured text a parser cannot use. It looks identical to a correct line at a glance.
No. It only checks conformance to RFC 9116's own rules about field syntax, required fields, and their formats — it has no opinion on whether the contact address is monitored, whether the policy page is any good, or whether the file is even reachable at the right location from a paste alone. Judging the substance is still a job for reading it.