Free Tool

Free security.txt Generator (RFC 9116)

Generate an RFC 9116 security.txt file so researchers can report vulnerabilities the right way. Add contact, expires, policy, and encryption fields and copy the file. Free, no signup.

Contact * (one per line - email or URL)

Expires * (when this file should be considered stale)

Encryption (optional)

Acknowledgments (optional)

Policy (optional)

Hiring (optional)

Canonical (optional)

Preferred-Languages (optional)

RFC 9116 requires at least one Contact and an Expires date. Fill both for a valid file.

security.txt

# security.txt - generated with U2L AI (u2l.ai/tools/security-txt-generator)
# Place at https://yourdomain.com/.well-known/security.txt

Expires: 2027-06-27T23:59:59.000Z

Save as /.well-known/security.txt at your domain root. For full compliance, serve it over HTTPS and consider signing it with PGP.

No signup required

Free forever

GDPR compliant

Quick Answer

A security.txt generator builds the RFC 9116 file that tells security researchers how to report vulnerabilities in your site. Add at least a Contact and an Expires date, plus optional Policy, Encryption, and Acknowledgments fields, and the tool outputs the file to place at /.well-known/security.txt. The U2L security.txt Generator runs in your browser. Free, no signup.

Quick Facts

security.txt is defined by RFC 9116 and lives at https://yourdomain.com/.well-known/security.txt.
Two fields are required: Contact (how to reach you) and Expires (when the file should be considered stale).
Contact can be an email (mailto:), a phone (tel:), or a URL - and you can list more than one.
Optional fields include Encryption, Acknowledgments, Policy, Hiring, Canonical, and Preferred-Languages.
Expires must be an ISO 8601 timestamp; refresh it before it passes (annually is common).
Serve it over HTTPS; for full compliance the file can be signed with an OpenPGP signature.
Browser-only and instant - the file is built locally and never sent to U2L servers.

How to create a security.txt file

Add contact and expiry, then copy the file.

1
Add your contact and expiry
Enter at least one Contact (a mailto: email or a reporting URL) and an Expires date. These two fields are required by RFC 9116.
2
Add optional fields
Fill in Policy, Encryption, Acknowledgments, Canonical, and Preferred-Languages as needed to give researchers a complete picture.
3
Deploy to /.well-known/security.txt
Copy the file and serve it over HTTPS at yourdomain.com/.well-known/security.txt. Update the Expires date before it lapses.

What is a security.txt Generator?

security.txt Generator is a tool that builds a standards-compliant security.txt file - the RFC 9116 text file that tells security researchers how to responsibly report a vulnerability in your website. You fill in a contact method, an expiry date, and any optional fields, and the generator outputs the correctly formatted file to publish at /.well-known/security.txt.

security.txt is to vulnerability reporting what robots.txt is to crawlers: a simple, predictable file at a well-known location that machines and humans both look for. Standardized as RFC 9116 in 2022, it gives ethical hackers an unambiguous channel to disclose a security issue instead of guessing at an email or giving up.

Without it, a researcher who finds a flaw on your site has no clear way to tell you - reports get lost in support queues, sent to the wrong address, or never made at all, leaving the vulnerability open. A published security.txt signals that you welcome disclosure and shortens the path from discovery to fix.

Security teams, site owners, and developers publish security.txt to formalize a vulnerability disclosure policy, meet customer and compliance expectations, and make their site a more cooperative target for the good actors who find bugs first.

How does a security.txt Generator work?

The generator assembles the file field by field in the order RFC 9116 expects. The two required fields come first: one or more Contact lines (a mailto: address, a tel: number, or an https URL to a reporting form) and a single Expires line marking when the file should no longer be trusted. You can list multiple contacts; the tool emits one Contact line per entry.

Optional fields follow: Encryption (a link to your PGP key so reports can be sent securely), Acknowledgments (a page thanking researchers), Policy (your disclosure policy), Hiring (security job openings), Canonical (the URI where this file lives), and Preferred-Languages (the languages your team reads). Each is emitted only if you fill it in, keeping the file clean.

Expires is formatted as an ISO 8601 timestamp because RFC 9116 requires a machine-readable expiry - the tool turns your chosen date into a full datetime value. The spec recommends keeping the expiry less than a year out and refreshing it, so the file always reflects a maintained, current contact path.

Everything runs in your browser; nothing is sent to U2L. The output is plain text you publish at /.well-known/security.txt over HTTPS. For full compliance you can add a Canonical field and sign the file with an OpenPGP signature, which proves the file is authentic - the generator gives you the unsigned body to sign with your own key.

Use Cases

How marketers, businesses, and developers use security.txt generator.

Publishing a vulnerability disclosure channel

Give researchers a clear, standard way to report security issues instead of hunting for an email or filing a support ticket that never reaches your security team.

Meeting security compliance expectations

Many security questionnaires and frameworks expect a published disclosure policy. A security.txt is a quick, visible way to demonstrate one.

Supporting a bug bounty program

Point researchers to your bounty platform and policy via the Policy and Contact fields so submissions arrive through the right channel.

Routing reports to the right team

A dedicated security@ contact and policy link ensure reports skip general support and land with the people who can triage and fix them.

Enabling encrypted vulnerability reports

Link your PGP key via the Encryption field so sensitive findings can be sent securely rather than in plaintext email.

Crediting researchers transparently

An Acknowledgments page linked from security.txt thanks contributors publicly, encouraging more responsible disclosure over time.

Standardizing across many domains

Security teams managing many sites publish a consistent security.txt on each so every property exposes the same reporting path.

Serving multilingual research communities

Use Preferred-Languages to tell international researchers which languages your team can handle, smoothing cross-border disclosure.

Learning the RFC 9116 format

See exactly which fields are required versus optional and how they should be ordered, building an accurate mental model of the standard.

security.txt Generator vs Alternatives

Side-by-side feature and pricing comparison with the top alternatives.

Feature	Manual writing	No security.txt	Copy from another site
Free, no signup		N/A
RFC 9116 field order enforced	Manual		Maybe
Required fields validated
ISO 8601 Expires formatting	Manual		Often stale
Multiple contacts supported	Manual		Maybe
Browser-only (no data sent)		N/A

security.txt Generator vs Writing security.txt by hand

You can write the file by hand from the RFC 9116 spec. It is short, and for a security professional the format is easy to follow.

The generator removes the small but consequential mistakes: forgetting the required Expires field, using a non-ISO date, mis-ordering fields, or omitting the mailto: scheme on a contact. It validates that the two required fields are present so you do not publish an invalid file.

security.txt Generator vs Copying another site's security.txt

Copying an existing file from another company is a tempting shortcut, but it carries their contacts, their expired dates, and their policy links.

Generating your own ensures the contacts route to your team, the Expires date is current, and the policy and acknowledgment links point to your pages. A stale or wrong-pointing file is worse than none, because researchers act on it.

Best Practices

Use a dedicated security contact

Point Contact at a monitored address like security@yourdomain.com or a reporting form, not a personal inbox or general support that may miss it.

Keep the Expires date current

RFC 9116 recommends an expiry under a year out. Set a reminder to refresh it so the file never signals stale, unmonitored contact details.

Serve it over HTTPS

Publish at https://yourdomain.com/.well-known/security.txt. A file served only over HTTP undermines trust in the very contact path it advertises.

Link a real disclosure policy

Use the Policy field to set expectations - scope, safe harbor, response times. Researchers are far more likely to engage when the rules are clear.

Offer encrypted reporting

Link a PGP key via Encryption so sensitive findings can be sent securely. It signals maturity and protects details of unpatched vulnerabilities.

Add the Canonical field

Stating the canonical URI of the file helps verify it is genuine and prevents confusion if it is mirrored or proxied elsewhere.

List multiple contacts in priority order

You can provide several Contact lines. Put the most preferred method first so researchers use your best channel by default.

Consider signing the file

For higher assurance, sign security.txt with OpenPGP. A valid signature proves the file is authentic and has not been tampered with.

Common Mistakes to Avoid

Omitting the required Expires field

RFC 9116 makes Expires mandatory. A file without it is invalid, and automated scanners will flag it. The generator includes Expires by default.

Letting the Expires date lapse

An expired security.txt signals abandonment, and researchers may not trust the contacts. Refresh the date on a schedule before it passes.

Forgetting the scheme on Contact

Contact values need a scheme: mailto: for email, tel: for phone, or https:// for a URL. A bare email address is not spec-compliant.

Publishing at the wrong path

It must be at /.well-known/security.txt (a root /security.txt is a deprecated fallback). The wrong location means tools and researchers never find it.

Serving it only over HTTP

An HTTP-only file is not compliant and is easy to tamper with. Always serve security.txt over HTTPS to protect the integrity of your contact details.

Pointing contacts at unmonitored inboxes

A valid file is useless if reports go to an address no one reads. Route Contact to a monitored security mailbox or ticketing queue.

Technical Specifications

Standard	RFC 9116
Location	https://yourdomain.com/.well-known/security.txt
Required fields	Contact, Expires
Contact format	mailto:, tel:, or https URL (one or more)
Expires format	ISO 8601 timestamp (recommended < 1 year out)
Optional fields	Encryption, Acknowledgments, Policy, Hiring, Canonical, Preferred-Languages
Transport	Must be served over HTTPS; OpenPGP signing recommended
Privacy	Built in your browser. No data sent to U2L.

Frequently Asked Questions

What is a security.txt file?

It is a standardized text file, defined by RFC 9116, that tells security researchers how to report vulnerabilities in your site. It lives at /.well-known/security.txt and lists a contact method, an expiry date, and optional policy and encryption details.

Where do I put the security.txt file?

At https://yourdomain.com/.well-known/security.txt, served over HTTPS. A file at the root (/security.txt) is a deprecated fallback; the well-known directory is the correct, current location that tools look for.

Which fields are required?

Two: Contact and Expires. Contact tells researchers how to reach you (email, phone, or URL) and Expires tells them when to stop trusting the file. Everything else - Policy, Encryption, Acknowledgments, and so on - is optional.

What format should the Contact field use?

A URI scheme: mailto:security@example.com for email, tel:+1-201-555-0123 for phone, or https://example.com/report for a form. A plain email address without mailto: is not compliant. You can list several contacts.

Why does security.txt need an Expires date?

Expires signals that the file is actively maintained. RFC 9116 requires it and recommends a value less than a year out. An expired file tells researchers the contacts may be stale, so refresh it before it lapses.

Can I list more than one contact?

Yes. You can provide multiple Contact lines. List them in order of preference so researchers reach for your best channel first - for example a dedicated security email followed by a reporting form.

Do I need to sign the file with PGP?

It is recommended but not required. An OpenPGP signature proves the file is authentic and untampered, which higher-assurance programs value. The generator produces the unsigned body that you can then sign with your own key.

What is the Encryption field for?

It links to your public PGP key so researchers can encrypt sensitive vulnerability details before sending them. This protects information about an unpatched flaw while it is in transit to your team.

What is the Canonical field?

Canonical states the URI where the security.txt file officially lives. It helps verify authenticity and avoids confusion if the file is mirrored, proxied, or copied elsewhere on the web.

Does having a security.txt improve security?

It does not patch anything itself, but it shortens the path from a researcher finding a bug to your team fixing it. Clear reporting channels mean vulnerabilities get disclosed responsibly instead of ignored or sold.

What is the Policy field?

Policy links to your vulnerability disclosure policy - the scope, rules, safe-harbor terms, and what researchers can expect. A clear policy makes researchers far more comfortable engaging with you.

How often should I update security.txt?

At minimum, before the Expires date passes - commonly once a year. Also update it whenever your contact methods, policy URL, or PGP key change so the file stays accurate.

Will scanners check my security.txt?

Yes. Automated tools and researchers look for the file and validate required fields and the expiry. A missing Expires or an expired date is commonly flagged, so a correctly generated file passes those checks.

Is Preferred-Languages important?

It is optional but helpful for international sites. It tells researchers which languages your team reads (for example en, es, fr), so reports come in a language you can act on quickly.

Is this generator free and private?

Yes. It is free with no signup, and the file is built entirely in your browser. Your contact details and links never leave your device.

Can a small site benefit from security.txt?

Absolutely. It is low effort and signals that you take security seriously. Even a single Contact and Expires line gives researchers a clear, trusted way to reach you if they find an issue.

Related Free Tools

Whois Lookup

Look up registrar, owner, creation date, expiry, and DNS for any domain. Free Whois data, no API key.

Free QR Code API

REST API for generating SVG and GIF QR codes. WiFi, vCard, URL, and text. Free, no API key, edge-cached.

DNS / CNAME Checker

Look up A, AAAA, CNAME, MX, TXT, NS records for any domain. Verify global DNS propagation in seconds.

SSL Certificate Checker

Inspect any SSL certificate: validity, issuer, chain, expiry, and protocol. Spot issues before users do.

HTTP Header Inspector

Inspect HTTP request and response headers for any URL. Cache, security, CORS, and server details.

URL Shortener Speed Test

Compare redirect response times across 10+ URL shorteners. Real measurements in your browser.

See all 50 free tools

Key Terms

security.txt: An RFC 9116 text file at /.well-known/security.txt that provides a standard channel for reporting security vulnerabilities to a site owner.
RFC 9116: The 2022 IETF standard that defines the security.txt format, its required Contact and Expires fields, and its optional fields.
Vulnerability disclosure: The process by which a researcher reports a security flaw to the affected organization so it can be fixed responsibly.
.well-known: A standardized URI directory for site-wide metadata files. security.txt, among others, is published under /.well-known/.
Expires field: The required security.txt field, formatted as an ISO 8601 timestamp, marking when the file's information should no longer be trusted.

Sharing your disclosure policy or security pages?

Use u2l.ai branded short links for your security policy, PGP key, and acknowledgments pages so they are easy to share and you can see engagement. Sign up free for branded links and analytics.