Generate RFC 9116 compliant security.txt files with contact, encryption, acknowledgments, and policy fields.
RFC 9116 gives vulnerability researchers one standardized place to look: /.well-known/security.txt. This tool writes that file for you. You fill in a contact email or URL, an expiry date, and optional fields (encryption key, disclosure policy, acknowledgments, preferred languages, hiring), and it renders the exact field: value text the standard specifies, converting bare emails to mailto: URIs and calendar dates to RFC 3339 timestamps. Everything runs in the browser, so your contact details never leave the machine. What users underestimate: generating the text is the easy part. Serving it at the well-known path over HTTPS, and renewing the mandatory Expires field every year, is where disclosure channels actually fail.
A concrete input and expected output from the current implementation.
Input
Contact: [email protected], Expires: December 31, 2026, Preferred-Languages: en
Expected output
Contact: mailto:[email protected] Expires: 2026-12-31T00:00:00Z Preferred-Languages: en
RFC 9116 requires Contact to be a URI, so the bare email becomes mailto:[email protected]. Expires must be a full RFC 3339 date-time, so the chosen calendar date is rendered as 2026-12-31T00:00:00Z (midnight UTC), which is the correct timestamp for that date. Both mandatory fields are present, and each line uses the standard's Field: value syntax.
Each form entry becomes one line of the file. Contact, Encryption, Acknowledgments, Policy, Canonical, and Hiring take URIs, and a bare email entered in Contact gets the mailto: prefix the RFC requires, since plain addresses are not valid values. Preferred-Languages is rendered as a comma-separated language list, and every line uses the standard's Field: value syntax with a colon and space, so the output parses cleanly against the RFC's grammar.
RFC 9116 requires Contact and Expires in every file, so a compliant generator keeps both in view. The expiry you pick is rendered as a full RFC 3339 timestamp with a timezone, because a bare date like 2026-12-31 does not satisfy the spec. The standard also caps Expires at one year ahead, which forces the yearly renewal most disclosure channels forget.
RFC 9116 defines Expires as an RFC 3339 date-time, so a plain date like 2026-12-31 is not a valid value; the generator renders the date you pick as a timestamp such as 2026-12-31T00:00:00Z. The one-year cap exists to force a periodic review, so plan to revisit the file yearly.
It belongs at https://yourdomain/.well-known/security.txt, and the well-known path is the whole point of the standard. Many servers also redirect requests from /security.txt to it, but you publish the file yourself; the tool cannot place it for you. After publishing, fetch the URL from outside your network and confirm it returns the file as text/plain.
The example and behavioral notes were checked against the browser implementation. Standards and primary references below define the relevant format, formula, or platform behavior.
Generate strong, random passwords with customizable length, character sets, and complexity requirements.
Analyze password strength with entropy scoring, crack-time estimates, and improvement suggestions.
Create cryptographically random strings for API keys, tokens, salts, and unique identifiers.
Create QR codes for URLs, text, Wi-Fi credentials, vCards, and more with customizable size and colors.
Scan and decode QR codes from uploaded images or your device camera to extract embedded data.
Compute MD5, SHA-1, SHA-256, and SHA-512 checksums to verify file integrity and detect tampering.