Gera Tools

Well-Known URIs Reference

All IANA-registered /.well-known/ URI paths with application and spec link.

A searchable reference for the IANA well-known URI registry — security.txt, openid-configuration, webfinger, acme-challenge, change-password, assetlinks.json and more — each with the protocol it serves, registry status and defining spec. Builds the full URL for your host. Runs in your browser.

What is the /.well-known/ path for?

RFC 8615 reserves the /.well-known/ prefix so protocols can publish site-wide metadata at a predictable location. Clients fetch these documents to discover endpoints, keys and policies without you having to invent a custom URL.

Discover site metadata with well-known URIs

The /.well-known/ path prefix is a small but powerful corner of the web. Defined by RFC 8615, it reserves a predictable location under every origin where protocols can publish site-wide metadata: security contacts, OAuth and OpenID endpoints, federation records, certificate-validation tokens and more. Instead of every standard inventing its own URL, they all register a suffix with IANA and live under /.well-known/. This reference lets you search that registry, see what each path is for, and build the exact URL for your own host.

How it works

Each entry in the IANA Well-Known URIs registry has a registered suffix — the text that follows /.well-known/ — plus the application that uses it, a registry status (permanent or provisional), and the spec that defines it. The full address is always:

https://<host>/.well-known/<suffix>

For example, the security disclosure file is https://example.com/.well-known/security.txt, and OpenID Connect discovery lives at https://example.com/.well-known/openid-configuration. When you enter a host, the tool strips any scheme or path you paste and assembles the canonical HTTPS URL for each entry so you can copy it straight into a request.

Tips and notes

  • Serve over HTTPS without auth. These documents are meant for automated clients (browsers, certificate authorities, federation servers), so they must be publicly reachable and return the correct content type.
  • security.txt needs an Expires field. RFC 9116 makes it mandatory, and many scanners flag a missing or past expiry.
  • ACME validation is temporary. The acme-challenge token files are written and removed automatically by your certificate client during issuance — you do not host them permanently.
  • Permanent vs provisional. Prefer permanent registrations when building something durable; provisional ones such as jwks.json or apple-app-site-association are conventions that work but are not yet locked to a single spec.