The web has files that every site agrees to place 'in a fixed spot.' So that browsers, search bots, certificate authorities, and operating systems can find certain metadata without guessing, sites place it at a predictable path under the host root. RFC 8615 standardizes this convention, defining paths of the form https://host/.well-known/<name>. Each name is registered in IANA's well-known URI registry.
Why /.well-known/ exists
Suppose a tool wants to know 'where is this site's security contact.' If every site had its own page structure, there'd be no way to find it. Agree instead that 'the security contact always lives at /.well-known/security.txt,' and any site can be queried with a single request to that path. /.well-known/ is that shared mailbox for machine-readable, site-level metadata.
GET /.well-known/security.txt HTTP/1.1
Host: example.com
HTTP/1.1 200 OK
Content-Type: text/plain
Contact: mailto:security@example.com
Expires: 2026-12-31T23:59:59.000Z
Preferred-Languages: ko, en
Policy: https://example.com/security-policyCommonly used well-known paths
/.well-known/security.txt(RFC 9116): a vulnerability-reporting channel. It carriesContact,Expires,Policy, and more so security researchers know where to report./.well-known/change-password: a standard path that redirects to the change-password page. Browsers and password managers wire their 'change password' button to it./.well-known/openid-configuration: an OpenID Connect provider's configuration document, publishing the authorization/token endpoints, supported algorithms, and JWKS location as JSON./.well-known/acme-challenge/<token>: during ACME certificate issuance (e.g. Let's Encrypt), the CA checks the response at this path to prove domain ownership./.well-known/jwks.json: publishes the set of public keys (JSON Web Key Set) used to verify JWT signatures.
Mobile app-association files
Mobile operating systems also link web and app via well-known paths. iOS's /.well-known/apple-app-site-association (AASA, JSON) declares which URLs open in the app (Universal Links). Android's /.well-known/assetlinks.json (Digital Asset Links) verifies the relationship between a domain and an app, enabling App Links and autofill sign-in. Both require the correct Content-Type (usually application/json) and a direct 200 with no redirect — get that wrong and deep links fail silently.
GET /.well-known/assetlinks.json HTTP/1.1
Host: example.com
HTTP/1.1 200 OK
Content-Type: application/json
[{"relation":["delegate_permission/common.handle_all_urls"],
"target":{"namespace":"android_app","package_name":"com.example.app",
"sha256_cert_fingerprints":["A1:B2:C3:..."]}}]robots.txt, ai.txt/llms.txt
Some files sit at the root by convention. /robots.txt predates the well-known registry as the crawler-rules file, and it lives at the root rather than under /.well-known/. More recently, informal conventions aimed at AI crawlers and LLMs have appeared, like /ai.txt and /llms.txt. Where robots.txt controls bot access, llms.txt is an attempt to curate key information so an LLM can summarize and understand the site. Note, however, that these are community proposals, not IETF standards yet.
Operational gotchas
Well-known files must usually be public with no authentication, and many (like the app-association files) are sensitive to redirects. When you deploy, verify that (1) the path returns 200 over HTTPS, (2) the Content-Type is correct, and (3) no auth middleware or SPA fallback routing intercepts it. A common failure is a frontend framework that rewrites every path to index.html, so the .well-known file responds as HTML and tools fail to parse it.