Security.txt Generator

security.txt is a plain text file that tells security researchers how to report a vulnerability on your website or product - which contact method to use, how long that information stays current, and where your disclosure policy lives. It's defined by RFC 9116, the IETF document most people just call the security.txt standard, and it belongs at yourdomain.com/.well-known/security.txt. This generator builds that file for you: pick an organization type or fill in your own Contact, Expires, and optional fields on the left, and you get a security.txt on the right that's already checked against what RFC 9116 actually requires.

It's built for anyone who needs a correct file without hand-memorizing RFC 9116's field syntax - a startup publishing its first disclosure channel, an open-source maintainer pointing researchers to an issue tracker, or a security team coordinating a bug bounty program alongside a PGP key and a formal policy.

The tool is split into two simple parts - your fields on the left, the live result on the right. There's nothing to install and nothing is sent anywhere until you choose to copy or download.

1. 1
   Choose your organization type (left side)

   Pick Startup/SaaS, Open Source, E-commerce, Personal Site, Enterprise, or Custom to pre-fill a sensible starting field set for that kind of project.
2. 2
   Add contacts and an expiry date (left side)

   Enter at least one Contact method and set an Expires date using a quick-pick button or a custom date - both are required by RFC 9116.
3. 3
   Add optional fields if you need them

   Open Optional Fields for Encryption, Canonical, Acknowledgments, Preferred-Languages, Policy, Hiring, and CSAF - none are required, but Encryption and Canonical are recommended.
4. 4
   Copy or download

   Every change updates the generated file and validation results immediately. Copy or download the file, then publish it at yourdomain.com/.well-known/security.txt.

Each row in the Validation Results panel is color-coded by severity:

• Green (Passed) - a confirmation that a check found nothing wrong, such as "Expires is valid and within the recommended window." No action needed.
• Amber (Warning) - a best-practice recommendation, like a missing Encryption field or an Expires date more than a year out. Not a spec violation, but usually worth addressing.
• Red (Error) - a genuine RFC 9116 violation: no Contact field, a missing or past-dated Expires, or a Contact URL using HTTP instead of HTTPS. Fix these before publishing.

Not directly. Google has never listed security.txt as a ranking factor, and there's no evidence it's read by ranking algorithms at all. Its value sits in a different layer, and it's worth being precise about which layer:

• Not a ranking factor. Publishing a security.txt will not move a page up or down in search results. Treat any claim otherwise with skepticism.
• A trust and due-diligence signal. Security researchers, enterprise procurement teams, and bug bounty platforms increasingly check for it as a baseline sign that an organization has a working vulnerability-disclosure process - closer to how a privacy policy or a security page factors into a buyer's trust decision than to a technical SEO fix.
• A diagnostic signal for you, not a Google metric. The validation results on this page tell you whether your own file is spec-correct - they're not a proxy for how Google or any other crawler treats your site.
• An indirect, real-world effect. A working disclosure channel means a researcher who finds an exploitable bug reports it to you privately instead of posting it publicly or selling it - and a public breach disclosure or defacement is one of the few security events that can tank both traffic and rankings at once. The connection to SEO is indirect, but not imaginary.

Say you run a small SaaS product and have never published a disclosure channel. You click the Startup / SaaS template and adjust it.

RFC 9116 is specific about location, and it differs from where earlier drafts told people to put the file:

• /.well-known/security.txt is authoritative. This is the path defined by RFC 9116 and RFC 8615's Well-Known URIs registry - it's what current scanners, browser extensions, and researcher tooling check first.
• Root /security.txt is a legacy fallback. Earlier drafts specified the file at the domain root; RFC 9116 deprecated that location but many older tools still check it. Serving a redirect from /security.txt to /.well-known/security.txt covers both without duplicating content.
• Serve it as plain text. Use a Content-Type of text/plain over HTTPS, the same way robots.txt is served - not wrapped in HTML.
• One file per domain, like robots.txt. Each subdomain and each protocol (http vs https) is checked separately, so a multi-subdomain organization needs a security.txt at every subdomain researchers might reasonably check.

RFC 9116 recommends digitally signing the file with a cleartext PGP signature, so anyone can verify it genuinely came from you and wasn't altered in transit. This generator deliberately does not handle PGP keys or signing - pasting a private key into any web page, including this one, is a bad security practice regardless of who built it. Instead: publish the plain file first, then sign it yourself with your own tooling (for example, gpg --clearsign security.txt), and publish the signed -----BEGIN PGP SIGNED MESSAGE----- version in place of the original. Reference your public key's URL in the Encryption field so researchers can verify the signature.

• Startups launching their first product - a single mailto: contact and a one-year Expires date gives researchers somewhere real to go instead of a generic support inbox that might not route security reports correctly.
• Open-source maintainers - point Contact at your GitHub Security Advisories URL or a dedicated security@ address separate from your general issue tracker, and add Acknowledgments to credit reporters publicly.
• Companies running a bug bounty program - link Policy to your program's scope and rules, and Contact to your bounty platform's submission page, so security.txt becomes the canonical entry point into the program.
• Enterprises with a security team - add Encryption for confidential reports, Hiring to surface open security roles to researchers who impress you, and CSAF if you publish machine-readable vulnerability advisories.
• Multi-region organizations - set Preferred-Languages to the languages your security team can actually respond in, so reports arrive in a language someone can act on.

• Leaving off the Expires field. RFC 9116 requires it. Without one, well-behaved tooling has no way to know whether the file - and the contact details in it - is still current.
• Publishing it once and forgetting it. A security.txt with an Expires date from two years ago signals that nobody is maintaining the disclosure channel - update it at least as often as the Expires date requires.
• Using an http:// contact URL. RFC 9116 requires HTTPS for URL-based Contact fields - an http:// link is a spec violation, not just a best-practice miss.
• Publishing only at the root, not at /.well-known/. Modern tooling checks /.well-known/security.txt first - a file that only exists at the root may simply never be found.
• Pointing Contact at an unmonitored inbox. A security.txt that routes to a mailbox nobody reads is worse than none at all - it wastes a researcher's time and can delay disclosure of a real issue.
• Treating it as legally binding without a Policy. Without a linked Policy, researchers don't know your rules of engagement (scope, safe harbor, disclosure timeline) - add one if you want reports handled the way you expect.

• Set a shorter Expires window than the maximum. A 3-6 month expiry forces a periodic review of whether the contact still works, rather than letting a full year pass unchecked.
• Test the Contact channel yourself. Send a real email to the address you list, or click through the URL, before publishing - a typo here quietly defeats the entire point of the file.
• Add Encryption once you have any real Contact volume. A PGP key lets a researcher report a critical, pre-disclosure vulnerability without it sitting in plaintext on a mail server.
• Calendar the renewal, not just the file. Put the Expires date on a recurring reminder so the file gets refreshed deliberately, not discovered stale by a researcher.
• Re-check after any domain or team change. A rebrand, an acquisition, or a security team reorg is exactly when a security.txt's Contact field quietly goes stale.
• Treat it as an operational commitment, not a static file. A security.txt is really a promise that someone is watching a specific inbox or URL. It's worth owning the same way you'd own an on-call rotation or an SLA - assign it to a person or team by name internally, even though the file itself only lists an address.

• robots.txt - a different well-known file entirely, controlling crawler access rather than vulnerability disclosure. Build one with the Robots.txt Generator.
• /.well-known/change-password - a sibling well-known URI (RFC 8615-based, from the W3C) that lets password managers jump straight to a site's password-change page, the same convention family security.txt belongs to.
• Vulnerability Disclosure Policy (VDP) - the fuller document a security.txt's Policy field typically links to, spelling out scope, safe harbor, and response timelines.
• Structured data (JSON-LD) - a different kind of machine-readable file that helps search engines understand a page rather than researchers report a bug. Build it with the Schema Markup Generator.
• Meta tags - page-level metadata for search and social previews, unrelated to disclosure but part of the same "get the fundamentals right" checklist. Build them with the Meta Tags Generator.

• security.txt is a voluntary convention - it cannot stop an attack or force a researcher to disclose responsibly, it only removes friction from the reporting process for those who want to do the right thing.
• The file must be served as UTF-8 plain text with a 200 status - a 404 or an HTML error page in its place looks like "no disclosure channel exists" to automated tooling.
• This tool checks syntax, required fields, and common logical mistakes, not your live server configuration - always confirm the final result by requesting yourdomain.com/.well-known/security.txt directly after publishing.
• PGP signing is not performed by this tool by design - sign the file with your own key and tooling after downloading it, never by pasting a private key into a browser page.

This generator runs entirely client-side: every contact, date, and URL you enter is processed by JavaScript in your own browser and never transmitted to AudEsto's servers or any third party. Refreshing or closing the tab clears everything, since nothing is stored remotely - copy or download the file before you navigate away if you want to keep it.

Ready to build your file? Scroll up and choose your organization type to get started - it only takes a few clicks.