#335 · Developer Tool

Security.txt Validator

Validate a security.txt file against the practical requirements of RFC 9116. The report checks required Contact and Expires fields, field syntax, URI schemes, expiration status, duplicate singleton fields, Canonical HTTPS usage, and language tags. Unknown extension fields are preserved in the report instead of being silently discarded. Use the line-numbered findings before publishing or renewing a vulnerability disclosure endpoint.

Developer Input

security.txt content
Ad space

How to use this developer tool

  1. Paste the security.txt content or load the included sample.
  2. Adjust any tool-specific option shown below the input.
  3. Select Validate File or press Ctrl/Cmd + Enter.
  4. Review the summary and findings, then copy or download the output.

What this developer tool does

Parses Field: value records line by line, ignores comments and blank lines, then applies required-field, singleton, date, URI, and known-field rules.

Parses Field: value records line by line, ignores comments and blank lines, then applies required-field, singleton, date, URI, and known-field rules.

A passing syntax check does not confirm that the contact channel works or that the Canonical URL serves identical content.

Example

Input

Contact: mailto:security@example.com
Expires: 2027-07-19T00:00:00Z
Preferred-Languages: en, ko
Canonical: https://example.com/.well-known/security.txt

Output

Valid: yes
Contacts: 1
Expires: 2027-07-19T00:00:00.000Z
Warnings: 0

Use cases

  • Review a deployment before changing production response headers.
  • Compare application and reverse-proxy configuration.
  • Create a reproducible finding for a security review or pull request.
  • Teach the practical effect of Security.txt Validator settings.

Tips for reliable output

  • Use the complete header value, including repeated fields.
  • Test the final response after CDN and proxy processing.
  • Keep a copy of the before and after output for review.
  • Do not treat a passing result as a penetration test.
  • Recheck after framework, server, or browser-policy updates.

Processing details

The validator accepts CRLF or LF files and reports malformed non-comment lines. Extension fields are allowed when their names follow the field-name grammar.

It does not fetch Canonical, Encryption, Policy, or Contact URLs and cannot verify an OpenPGP clearsignature.

Frequently asked questions

Which fields are mandatory in an RFC 9116 security.txt file?

The checker reports this directly from the supplied security.txt content and shows the relevant value in its output.

Why does a past Expires date invalidate security.txt?

Use the result together with the browser and server behavior you support; the page does not make remote requests.

Are unknown extension fields allowed in security.txt?

Review the generated finding before deployment, especially when proxies or CDNs can alter headers.

Must the Canonical security.txt URL use HTTPS?

The implemented rule follows current HTTP security-header practice and flags values it cannot recognize.

Does this validator verify a PGP-signed security.txt file?

Retest with the exact production response because small header changes can affect the conclusion.

Checks and output

StageWhat is reported
ParseRecognized input fields and values
ValidateInvalid, missing, or conflicting settings
ExportText, CSV, and JSON when structured data is available

HTTP & Security Headers

Browse more tools for HTTP behavior, browser policies, cookies, CORS, CSP, and response-header security.

View HTTP & Security Headers