security.txt Parser (RFC 9116)

Everything runs locally in your browser — nothing is uploaded

Input

Drop a file here to load its contents

Output

Press Ctrl/⌘ + Enter to run · Press Esc to clear

A `security.txt` is a plain text file at a site root whose job is to tell security researchers who to contact about a vulnerability. Without one, researchers can only guess — guess whether it is `security@` or `abuse@`, whether there is a bug bounty, whether encrypted reports are welcome. Guessing wrong means the report is published anyway or never sent at all. The syntax is simple enough that "one `field: value` per line" tempts everyone into writing a few lines of parsing code. But what actually matters in RFC 9116 is two hard requirements that hand-written parsers almost never check: · `Expires` is mandatory, and must be an RFC 3339 instant with a timezone. Without it the file is non-conformant; and an expired file is supposed to be treated as if it did not exist — which is the dangerous part, because it means the contact details you believe you are publishing went stale long ago while the file itself still looks perfectly fine. · `Contact` is mandatory, and every entry should be a protocol-qualified URL (`mailto:` or `https:`). A bare `security@example.com` looks entirely normal but many parsers drop that entry outright. So the output here is not a field listing — it is a verdict on whether the file is any use. ⚠️ It is offline: it will not fetch `https://example.com/.well-known/security.txt` for you, and it cannot verify that an address exists. Fetch the file yourself — open that URL in a browser, or `curl` it — and paste the contents here.

Features

⚠️ The first row is the verdict: valid, expired, no Expires, or an unreadable Expires — each with its own colour
When Expires is missing or malformed it explains why that makes the file useless, rather than just flagging a syntax error
Expires must carry a timezone (`Z` or `±HH:MM`) — an instant without one has no defined meaning, and different timezones would disagree about when the file expires
Values that are not URLs in Contact / Policy / Canonical and friends are flagged one by one, with the line number
Field names are case-insensitive, `#` comments are listed separately, and a repeated field keeps every value (Contact is meant to be repeatable)
Unrecognised fields are listed — the RFC requires them to be ignored, so a mistyped field name is dropped silently rather than reported
Understands PGP clearsigned files: the body is extracted from the signature block and `- ` dash-escaping is undone
An aligned two-column report you can copy as a whole
Everything runs in your browser; what you paste is never uploaded

How to use

Get the file: open `https://<domain>/.well-known/security.txt` (older sites may only have `security.txt` at the root)
Copy the whole thing and paste it in
Read the verdict first, then the field list
Anything wrong points at a specific line number, so you can go back and fix that line

FAQ

Can this fetch someone else’s security.txt for me?: No. This is a static site with no backend, and every tool runs in your browser only — that is the price of the "data never leaves the browser" rule. To get the file, just open `https://domain/.well-known/security.txt` in a browser (it is plain text and will display directly), or `curl https://domain/.well-known/security.txt`. Some sites publish it in both locations; the spec prefers the `/.well-known/` one.
What happens when Expires has passed?: RFC 9116 says an expired file should be treated as if it does not exist. That requirement is the whole point of having Expires at all: contacts change, domains change hands, teams dissolve. A file written in 2019 that stayed valid forever could send a researcher to a mailbox that has nothing to do with the site any more, which is worse than having no file. So many scanners skip expired files outright, meaning the contact details you think you publish may already be dead. Set the expiry a year or two out and update before it lapses.
Should Contact hold an email or a URL?: Both need a protocol: `mailto:security@example.com` or `https://example.com/report`. A bare `security@example.com` is readable to a human but is not a URI, and parsers work on URIs — many implementations discard that entry. You may list several Contact entries (the spec allows it), conventionally most-preferred first: a form URL followed by an email, say. If encrypted reports are welcome, point `Encryption:` at the key’s URL (do not paste the key itself; that field must also be a URI).
Why does a mistyped field name not raise an error?: Because the spec says so: unrecognised fields must be ignored. That rule exists for forward compatibility — when the RFC gains a new field, older parsers should not reject the whole file for not knowing it. The price is that a typo (an `Acknowledgment` missing its final s, a `Preferred-Language` likewise) produces no warning at all; the entry is simply dropped. So unrecognised field names are listed here: not treated as errors, but made visible.
What is the PGP clearsigning about?: The spec recommends (does not require) signing the whole file with PGP cleartext signing, which wraps the body in `-----BEGIN PGP SIGNED MESSAGE-----` and appends a signature block. The benefit is that others can confirm the file really came from you and was not altered in transit. This tool extracts the body from the signature block and undoes the `- ` dash-escaping the cleartext format requires, but it does not verify the signature — that needs a public key, and the key needs the network. Use `gpg --verify` for that.

Related tools

Config Validator

Web

Check a package.json, .env, robots.txt, sitemap.xml or HTTP headers. Findings come in three levels — errors, warnings, suggestions — each with a reason.

Magic Bytes

Web

Identify a file from its first bytes. Covers 59 common formats, handles signatures at an offset, and looks up the magic bytes for a given format.

HTTP Status Codes

Web

Look up an HTTP status code for its meaning, 1xx–5xx class, typical uses and common traps. Runs entirely in your browser.

URL Parser

Web

Parse a URL into scheme, host, port, path, query parameters and fragment, with each parameter shown raw and decoded. Runs entirely in your browser.

User-Agent Parser

Web

Parse a user agent into browser, version, OS, device type and engine, and see which rules matched. Pattern matching only. Runs entirely in your browser.

MIME Types

Web

Look up a MIME type from an extension, or the default extension for a media type. Common types only. Runs entirely in your browser.

← Back to all tools