.well-known URL Reference

Browse the IANA .well-known URI registry with descriptions, RFC references, and implementation guidance.

Tested tool guide Tested browser tools Checked August 16, 2026

What .well-known URL Reference does, with a checked example

This tool presents the IANA Well-Known URIs registry as a readable reference: every path suffix registered for the /.well-known/ prefix on HTTP(S) origins, each with a plain-language description, its permanent or provisional status, the change controller, and the RFC or vendor specification that defines it. The prefix itself comes from RFC 5785, which reserved it so clients can discover host metadata at a predictable location on any origin. The thing most people get wrong is treating the registry as a complete map of well-known paths on the internet: it records registered suffixes only, and an entry describes the name, not the payload - the linked specification is where the file format or endpoint behavior is actually defined.

Worked example

A concrete input and expected output from the current implementation.

Input

security.txt

Expected output

Entry: security.txt. Status: permanent. Change controller: IETF. Reference: RFC 9116. Description: a plain-text file at https://<your-domain>/.well-known/security.txt that tells security researchers and automated scanners where to report vulnerabilities in your site. Implementation note: RFC 9116 requires at least one Contact field and one Expires field; all other fields are optional.

security.txt is one of the most widely used registered suffixes, so a search resolves to a full entry card. The registry row supplies the status and the RFC reference, and the implementation note comes from RFC 9116's field definitions, which make Contact and Expires the only required fields.

How the result is produced

Registry structure

Entries mirror the IANA registry that RFC 5785 created with two registration tiers. Permanent entries require an IETF-reviewed specification, typically an RFC. Provisional entries are approved by an IANA-appointed expert and may later be promoted to permanent. Each row shows the URI suffix (everything after /.well-known/), the change controller, the status, and the reference. Because IANA publishes machine-readable copies of the registry, the list tracks new suffixes and status changes.

Search and lookup

Search filters the suffix list by text and by status. Opening an entry shows the description plus links to the defining document, usually at rfc-editor.org or the vendor's site. The registry itself never contains payload formats, so the descriptions here summarize what each entry is for, and the linked document is the authority for the exact syntax, required fields, and behavior.

Good uses

You run an OAuth or OpenID Connect authorization server and need the registered discovery suffix - /.well-known/openid-configuration - plus the metadata format clients will expect.
You are setting up ACME domain validation for certificate issuance and must serve challenge tokens at the exact /.well-known/acme-challenge path the certificate authority will fetch.
You are naming a new metadata endpoint for your product and want to check whether the suffix you plan to use is already registered, so you reuse the existing one or start an IANA registration instead.

Limits and checks

Absence from the registry is not a verdict: several real-world /.well-known/ paths are defined by vendor specifications outside the IETF process, and RFC 5785 advises against unregistered use of the prefix rather than strictly forbidding it.
Permanent versus provisional describes the registration route, not reliability or deployment: provisional entries can be in universal production use, while a permanent entry can still be rarely deployed. Do not rank trustworthiness by status.
The registry lists names, not shapes: some suffixes are single files (security.txt) and others are directory prefixes holding many endpoints (acme-challenge). The payload format is never in the registry - only in the linked specification.

Common questions

Can I put my own files under /.well-known/ without registering?

Technically yes - the prefix lives on your origin and nothing stops you serving anything there. But RFC 5785 advises servers not to use /.well-known/ for unregistered purposes, because a later registration could collide with your path. The safe routes are a provisional registration through IANA, or a path outside the reserved prefix.

Does registration guarantee clients will fetch my well-known file?

No. The registry is a naming agreement, not a deployment directory: clients look under the prefix only when their own specification tells them to, and most treat a missing or malformed file as 'this service is absent'. Registration also does not change how the path resolves - a well-known URI is origin-relative, so whichever origin the client is talking to must actually serve it.

References and verification

The example and behavioral notes were checked against the browser implementation. Standards and primary references below define the relevant format, formula, or platform behavior.

Related Tools

JSON Formatter & Validator

Format, validate, and beautify JSON with syntax highlighting and error detection.

Base64 Encoder / Decoder

Encode text or files to Base64 and decode Base64 strings back to their original form.

SQL Formatter & Beautifier

Format and indent SQL queries for better readability across all major dialects.

HTML to Markdown Converter

Convert HTML markup into clean Markdown syntax with support for tables and lists.

Markdown to HTML Live Preview

Write Markdown and see the rendered HTML output in real time with live preview.

Diff / Patch Viewer

Visualize unified diffs and patch files with color-coded additions and deletions.