DevTools Logo

Security.txt Generator

Security.txt Generator

Create an RFC 9116 security.txt so researchers know how to report vulnerabilities — built in your browser

Fields

Contact and Expires are required. Contact and Encryption may have one value per line.

Examples

Create a minimal security.txt

Input
Contact: mailto:security@example.com
Expires: 2027-01-01T00:00:00Z
Preferred-Languages: en
Canonical: https://example.com/.well-known/security.txt
Output
Contact: mailto:security@example.com
Expires: 2027-01-01T00:00:00Z
Preferred-Languages: en
Canonical: https://example.com/.well-known/security.txt

The generator keeps the required fields, includes the populated optional fields, and terminates the file with a newline.

Publish a complete disclosure record

Input
Contact: mailto:security@example.com and https://example.com/report
Expires: 2026-12-31T23:59:59Z
Encryption, acknowledgments, languages, canonical, policy and hiring URLs populated
Output
Contact: mailto:security@example.com
Contact: https://example.com/report
Expires: 2026-12-31T23:59:59Z
Encryption: https://example.com/pgp-key.txt
Acknowledgments: https://example.com/hall-of-fame
Preferred-Languages: en, fr
Canonical: https://example.com/.well-known/security.txt
Policy: https://example.com/security-policy
Hiring: https://example.com/jobs

A newline-separated Contact value becomes two Contact lines, followed by each populated optional field in the generator's fixed order.

About this tool

A security.txt file gives vulnerability researchers a standard place to find your reporting channels, disclosure policy, encryption key, acknowledgments page and security hiring information. This generator assembles those fields in the order used by RFC 9116 and reminds you when the required Contact or Expires value is missing.

Contact and Encryption values can be repeated when their input contains newline-separated entries; blank entries are removed. Other blank fields are omitted, surrounding whitespace is trimmed, and the generated text always ends with a newline so it is ready to serve as a plain-text file.

The form does not validate URI schemes, language tags or expiry dates. Review every value, make sure Expires is a future UTC timestamp, then serve the result from /.well-known/security.txt over HTTPS.

How to use

  1. Add a reporting contact

    Enter at least one Contact URI, such as a monitored mailto address. Contact is required, and the generator can emit repeated Contact lines from newline-separated values.

  2. Set the expiry

    Enter a future date and time in the Expires field, ideally as an RFC 3339 UTC timestamp such as 2027-01-01T00:00:00Z.

  3. Add optional policy details

    Provide an encryption-key URL, acknowledgments page, preferred languages, canonical URL, disclosure policy or security-jobs page where applicable.

  4. Copy and publish

    Copy the generated text, save it as security.txt, and serve it at /.well-known/security.txt on the relevant HTTPS origin.

Use cases

Launching a vulnerability disclosure program

Publish a monitored reporting address and policy URL before inviting researchers to test or report security issues.

Standardizing contacts across domains

Generate consistent files for production, documentation and API domains while setting the correct Canonical URL on each origin.

Advertising encrypted reporting

Point researchers to a hosted PGP key when reports may contain sensitive exploit details or customer data.

Maintaining disclosure metadata

Regenerate the file when contacts, policy pages, hiring pages or the required expiry timestamp change.

Common mistakes

Mistake:Publishing the file without Contact or Expires.

Fix:Populate both required fields and resolve the warning before deployment.

Mistake:Leaving an old expiry timestamp in production.

Fix:Set a future timestamp and schedule a review well before it expires.

Mistake:Serving the file only from an arbitrary path.

Fix:Serve it from /.well-known/security.txt over HTTPS; use Canonical to identify the authoritative location.

Mistake:Assuming the form validates every URI and language value.

Fix:Verify schemes, destinations, comma-separated language tags and policy URLs independently before publishing.

Frequently asked questions

Related guides

security.txt: Tell Researchers How to Report Vulnerabilities

What the RFC 9116 security.txt file is, the required and optional fields, where to host it, and why every production site should have one.

Four Files Every Production Website Should Have

robots.txt, sitemap.xml, security.txt, and the web app manifest — the small root-level files that improve crawling, security, and installability.

The Legal and Trust Pages Every Web App Should Ship

A practical checklist of the legal, privacy, and security pages users and regulators expect — and how to generate each one.

The /.well-known/ Directory: What It Is and What Goes There

A single reserved path holds a surprising amount of a site's machine-readable metadata — from security contacts to certificate validation. Here's the tour.

References & standards

Related tools

AES Encryption

Encrypt and decrypt text with AES-GCM and a passphrase, fully in your browser. Uses PBKDF2 key derivation and the Web Crypto API — your data and keys never leave your device.

Basic Auth Generator

Generate an HTTP Basic Authentication header from a username and password. Produces the Authorization header and ready-to-use curl and fetch snippets. Runs fully client-side.

Bcrypt Generator & Verifier

Hash passwords with bcrypt and verify hashes — choose your cost factor (rounds 4–15), get a secure hash instantly, and check whether a password matches a hash. Runs entirely in your browser.

BIP39 Mnemonic Generator

Generate and validate BIP39 seed phrases locally for testing

Checksum Calculator

Compute file checksums (SHA-1, SHA-256, SHA-384, SHA-512) in your browser with the Web Crypto API

Client-Side File Encryptor

Encrypt any file with AES-256-GCM and PBKDF2 directly in your browser — no uploads, no accounts, wrong passwords fail loudly.