FreeToolsForWebFree tools for web. No sign-up.

security.txt Generator — Create and Validate an RFC 9116 File

Create a valid security.txt (RFC 9116) with contact, expiry, encryption and policy fields, check an existing one, and download it for /.well-known/.

Email addresses, https:// report forms or phone numbers. Bare emails get mailto: added. List the preferred one first.

RFC 3339 date-time, less than a year ahead. Put a reminder in your calendar to renew it before it lapses.

URL of your PGP public key (https://, dns: or openpgp4fpr:), not the key itself.

Comma-separated language tags, e.g. en, fr, pt-BR.

The https:// URL(s) where this file lives. Required in practice if you sign it.

Your vulnerability disclosure policy: scope, safe harbour, how you respond.

A page thanking researchers who reported issues (hall of fame).

Security job openings.

For vendors publishing machine-readable advisories: URL of provider-metadata.json.

Valid: all required fields present and every value matches RFC 9116.

security.txt
…
Where to put it
  • Serve it at https://yourdomain.com/.well-known/security.txt over HTTPS, as text/plain; charset=utf-8. Optionally redirect /security.txt to it.
  • Next.js, Astro, Vite and most static hosts: save it as public/.well-known/security.txt. WordPress, Apache or nginx: create a .well-known folder in the web root.
  • Each subdomain that serves its own site should have its own file (or point visitors to the main one in a comment).
  • Optional: sign it with gpg --clearsign security.txt and publish the signed output; include Canonical so the signature covers the location.

Runs entirely in your browser. Nothing you enter is sent to us or stored. Browse all free tools.

Found a problem, or something that could be better? We read every message and we fix things quickly.

This free security.txt generator creates the small text file, standardised as RFC 9116, that tells security researchers how to report a vulnerability on your site. Fill in a contact, an expiry date and optionally your encryption key, disclosure policy, acknowledgments page, preferred languages and canonical URL; the file is validated against the RFC as you type and downloads as security.txt, ready to upload to /.well-known/security.txt.

Without it, someone who finds a hole in your site has to guess where to send it, and reports end up in a support inbox, on social media or nowhere. The file takes five minutes and is checked by many security scanners and bug-bounty researchers. The second tab validates a file you already publish. The tool does not sign the file (use gpg for that) and does not fetch your live file, because the page makes no network requests.

How to use

  1. Enter at least one Contact: a security email, a report form URL or a phone number. Put the preferred one first.
  2. Set Expires with one of the buttons (six months is a good default) or type an RFC 3339 date-time.
  3. Add the optional fields you have: the URL of your PGP key, your disclosure policy, a thanks page, languages you read, and the canonical URL of the file.
  4. Fix anything flagged in red; amber items are recommendations.
  5. Download security.txt and publish it at https://yourdomain.com/.well-known/security.txt, served as text/plain. Set a reminder to update Expires.

Frequently asked questions

What is security.txt?

A plain-text file at /.well-known/security.txt that lists how to report security vulnerabilities in a website or product. It was published as RFC 9116 by the IETF in April 2022. Only two fields are required, Contact and Expires; the rest (Encryption, Acknowledgments, Preferred-Languages, Canonical, Policy, Hiring) are optional.

Where do I put the security.txt file?

At https://yourdomain.com/.well-known/security.txt, served over HTTPS with the content type text/plain; charset=utf-8. The legacy location /security.txt at the root is still read by some tools; you can serve a copy there or redirect it. In Next.js, Astro, Vite and most static hosts, place the file in public/.well-known/. Each hostname that is its own site should have its own file.

Why is the Expires field required?

So stale contact details are not trusted forever. RFC 9116 makes Expires mandatory and recommends a date less than a year ahead; when it passes, researchers and scanners should treat the file as out of date. Six months with a calendar reminder to renew is a practical rhythm, and the generator warns when the date is past or more than a year away.

Should I sign security.txt?

Signing is optional but recommended. Run gpg --clearsign security.txt with a key whose public part you publish (the Encryption field can point to it) and upload the signed output instead. If you sign, include a Canonical field, so a signed copy taken from one URL cannot be passed off as valid at another.

Can I use a bug bounty platform link as the contact?

Yes. Contact accepts any https:// URI, so a HackerOne, Bugcrowd, Intigriti or YesWeHack program page, or your own report form, is valid. Many organisations list both a platform link and an email address, in order of preference.

RFC 9116 fields at a glance

• Contact (required, repeatable): mailto:, https: or tel: URI. Order indicates preference.

• Expires (required, exactly once): RFC 3339 date-time such as 2027-04-30T23:59:59Z; recommended less than a year ahead.

• Encryption (repeatable): where to get your public key, as https://, dns: (OPENPGPKEY record) or openpgp4fpr: (fingerprint). Never paste the key itself.

• Acknowledgments (repeatable): a page thanking reporters.

• Preferred-Languages (once): comma-separated language tags, e.g. en, fr.

• Canonical (repeatable): the URL(s) where this file is meant to live.

• Policy (repeatable): your vulnerability disclosure policy.

• Hiring (repeatable): security-related jobs.

• CSAF (repeatable, registered by OASIS): the provider-metadata.json of a CSAF advisory feed.

Web URIs must use https://. Lines starting with # are comments.

What to write in your disclosure policy

The Policy link is where researchers learn whether it is safe to report. State the scope (which domains and apps), what is out of scope (denial of service, social engineering, automated scanner output), how fast you will acknowledge and fix reports, whether you offer rewards, and a safe-harbour statement that you will not take legal action against good-faith research that follows the policy. A short, clear page gets more useful reports than a long legal one.

security.txt and robots.txt

They live side by side but do different jobs: robots.txt asks crawlers what not to fetch, security.txt tells people how to reach your security contact. Do not list security.txt or /.well-known/ under Disallow; researchers and scanners need to read it, and blocking it in robots.txt does not hide it anyway.

Related free tools

  • Robots.txt Generator — Build a robots.txt with presets for allow-all, staging and WordPress, an AI crawlers section (block training, keep AI search), and warnings for the mistakes that de-index sites.
  • Password Generator — Generate a strong random password, a memorable passphrase or a PIN. Runs entirely in your browser, nothing is sent or stored.
  • Meta Tag Generator — Fill in a page's title, description and social card details; get a complete, correctly escaped <head> block with live length counters.
  • JWT Decoder — Decode a JWT's header and payload, read the expiry in plain language, verify HS, RS, PS and ES signatures, or sign a new token. Nothing leaves your browser.