TLS Extensions Database: Codes, Names, and RFCs

Direct answer: Use the IANA Transport Layer Security (TLS) Extensions registry as the authoritative lookup for TLS extension codepoints and registered names. In the ExtensionType Values table, match the numeric value with its Extension Name, TLS 1.3 handshake context, DTLS-only status, recommendation status, reference, and comments. Then open the referenced RFC for wire format and protocol behavior. The registry is an index and allocation record; it is not a replacement for the specification.

What the TLS extensions database contains

IANA’s page groups several related registries together. The first task in any lookup is confirming that you are reading TLS ExtensionType Values, rather than a neighboring namespace:

Registry	What it identifies	Common mistake
TLS ExtensionType Values	Numeric TLS extension codepoints and names	Treating every number as an implemented extension
TLS Certificate Types	Certificate type identifiers	Using its values as extension codepoints
TLS Certificate Status Types	Certificate status identifiers	Confusing status types with extension names
ALPN Protocol IDs	Application-Layer Protocol Negotiation protocol identifiers	Assuming an ALPN ID is an ExtensionType value
CachedInformationType Values	Cached information types	Looking up the wrong table because it is on the same page
TLS Certificate Compression Algorithm IDs	Certificate compression algorithms	Comparing algorithm IDs as if they were extensions

The registry page reports a last-updated date of 2026-08-11. Assignments and annotations can change, so use the live page when publishing software documentation, validating a packet, or advising on a new registration.

How to look up a TLS extension number and name

Open the live IANA page. Bookmark the registry URL rather than copying an old static list.
Locate ExtensionType Values. Do not begin in ALPN, certificate, or compression registries.
Search the Value column. Enter the decimal codepoint from a ClientHello, ServerHello, EncryptedExtensions, or another handshake message.
Read the complete row. Record the registered name, TLS 1.3 context, DTLS-only marker, recommendation, reference, and comment.
Open the reference. The RFC defines payload encoding, legal handshake locations, negotiation rules, and version constraints.
Record the lookup date. This makes later changes in assignment or recommendation status visible.

If you start with a name instead, search the Extension Name column and verify the numeric value. Preserve the registry’s exact spelling, including historical rename notes where shown.

A registry row identifies the codepoint; the RFC supplies the protocol behavior.

Understanding every column

Value

Value is the numeric codepoint. A row may be a named assignment, Reserved range, or Unassigned value. Reserved and Unassigned are different states: neither should be described as an active extension, and an unassigned number is not evidence that an implementation may safely use it.

Extension Name

This is IANA’s registry label. It is useful for a codepoint list and for cross-referencing packet-analysis tools, but the label alone does not specify behavior. If a row includes a rename or historical qualification, keep that context in your notes.

TLS 1.3 context

The context field indicates handshake messages in which an extension is defined for TLS 1.3. IANA uses abbreviations such as:

CH: ClientHello
SH: ServerHello
EE: EncryptedExtensions
CT: Certificate
CR: CertificateRequest
NST: NewSessionTicket
HRR: HelloRetryRequest

These labels are context markers, not a complete wire-level description. The RFC explains whether a field is sent conditionally, how it is echoed, and what a peer must do when it is absent or unexpected.

DTLS-Only

A DTLS-only designation identifies entries specific to Datagram Transport Layer Security in the registry. Read it with the referenced specification. Do not infer broad TLS support or security properties from this column alone.

Reference

The reference points to the document governing the entry. Follow it for normative details. A registry row can tell you which document to read, but not replace that document.

Comment

Comments add qualifications that do not fit the compact table. The registry notes that entries added after IESG approval of RFC 9851 are intended for TLS 1.3 or later and do not thereby impose a similar DTLS requirement. Treat that statement as conditional on when the entry was added.

Assigned, reserved, and unassigned values

When someone asks, “Is TLS extension value N reserved or unassigned?”, answer from the current IANA row and state the date checked.

TLS 1.3 context labels show where an extension may appear in the handshake.

Status	Meaning for implementers	Safe documentation wording
Assigned	IANA has a named registration and reference.	“Codepoint N is registered as …”
Reserved	The registry intentionally marks the value or range for special handling.	“N is reserved; do not treat it as an available extension number.”
Unassigned	No active assignment is recorded at the time of lookup.	“N is currently unassigned in the live registry.”

Never turn a reserved or unassigned value into a private production extension by assumption. Experimental use, if permitted by a relevant specification or deployment policy, still needs explicit documentation and collision planning.

Comparing two TLS extensions correctly

Two rows appearing near each other are not automatically alternatives. Compare them using the same six axes:

Numeric value and exact registered name.
TLS 1.3 handshake-message context.
DTLS-only designation.
Recommendation status.
Assigned, reserved, or unassigned state.
Governing RFC or other reference.

Then compare the RFC-defined purpose and payload. A ClientHello extension and a NewSessionTicket extension may both be registered, but they operate in different messages and solve different problems. State the protocol version and transport scope in your comparison.

Programmatic lookup and reproducible notes

For a one-off investigation, a browser search is enough. For a decoder, documentation build, or compliance check, keep the source URL and lookup date beside the result. The following commands retrieve the registry page for local inspection.

cURL

curl -L 'https://www.iana.org/assignments/tls-extensiontype-values' -o tls-extensions.html

Python

import requests

url = 'https://www.iana.org/assignments/tls-extensiontype-values'
r = requests.get(url, timeout=30)
r.raise_for_status()
with open('tls-extensions.html', 'wb') as f:
    f.write(r.content)
print('saved', len(r.content), 'bytes')

Node.js

const res = await fetch('https://www.iana.org/assignments/tls-extensiontype-values');
if (!res.ok) throw new Error(`${res.status} ${res.statusText}`);
const html = await res.text();
console.log(`received ${html.length} characters`);

These examples fetch the authoritative page; parsing should be conservative. Match the table heading and column names before extracting rows, and preserve text such as Reserved, Unassigned, DTLS-Only, and recommendation letters exactly. A parser that assumes every table on the page has the same columns can silently read a neighboring registry.

Building a reliable extension lookup workflow

Normalize input. Accept decimal codepoints and reject negative values or values outside the field width your protocol parser supports.
Separate namespaces. Label records as ExtensionType, ALPN, certificate status, or another registry before storing them.
Keep raw and interpreted values. Store the original registry text alongside parsed fields so a future annotation can be reviewed.
Resolve references. Link the RFC or specification and capture its version-specific rules.
Handle unknown values. Display Unknown, Reserved, or Unassigned distinctly; do not map all three to “unsupported.”
Refresh deliberately. Recheck the live registry before releases that depend on new allocations or recommendation changes.

Common errors and fixes

Symptom	Likely cause	Fix
A known ALPN identifier is missing from your extension list.	You searched the ExtensionType table for an ALPN registry value.	Use the ALPN Protocol IDs registry on the same IANA page.
Your parser reports every number as assigned.	It ignores Reserved and Unassigned rows or ranges.	Model status as a separate field and preserve the registry label.
An extension appears valid in ClientHello but fails in another message.	You treated the name as global and ignored TLS 1.3 context.	Check the context column and read the referenced RFC.
You call an N recommendation obsolete.	You interpreted recommendation status as implementation support.	Report the literal status and consult the RFC for deployment guidance.
A DTLS implementation accepts a TLS-only extension.	Transport scope was inferred instead of checked.	Read the DTLS-only column and governing specification.
A copied list disagrees with IANA.	The copy is stale; assignments and comments changed.	Use the live registry and record its last-updated date.
The fetched page cannot be parsed.	HTML structure or table order changed.	Select by heading and column names, add parser tests, and fail closed when the expected table is absent.

Performance, reliability, and operational notes

A local cached copy makes repeated lookups fast, but it can become stale. For production tooling, cache the page with an explicit refresh interval, retain the retrieval timestamp, and make a registry refresh observable. Do not make a network request on every packet decode. Prefer a generated data file reviewed during dependency updates, with a fallback that clearly marks data as stale.

When a release depends on an allocation, verify the live entry immediately before publishing. If an RFC and registry comment appear to conflict, report the scope and date of each source rather than merging them silently. The registry is authoritative for assignment status; the referenced RFC is authoritative for protocol behavior.

Registration guidance for new codepoints

There is no single universal allocation path. IANA’s guidance for RFC authors says to use the exact registry name and follow the procedure specified for that registry. The TLS Extensions page points to RFC 8126 and RFC 9847, and procedures depend in part on recommendation status. If the Specification Required procedure applies, requests can be sent to iana@iana.org or submitted through IANA’s application form, as described in the registry notes. Check the current procedure before advising an author or filing a request.

Or skip the browser setup

If you need a clean image of the live registry for documentation, a visual diff, or an AI-assisted review, ScreenshotNeo provides a website screenshot API and MCP server. One GET request returns PNG, JPEG, WebP, or PDF. See the ScreenshotNeo API documentation for the complete option list.

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://www.iana.org/assignments/tls-extensiontype-values -o shot.webp

import requests
r = requests.get("https://api.screenshotneo.com/v1/shot", params={"access_key": "YOUR_API_KEY", "url": "https://www.iana.org/assignments/tls-extensiontype-values"}, timeout=90)
open("shot.webp", "wb").write(r.content)

const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://www.iana.org/assignments/tls-extensiontype-values' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);

Before capture, ScreenshotNeo accepts cookie or consent banners and removes more than 60 known consent platforms, newsletter popups, and chat widgets; each step can be turned off. Bot checks, blank pages, timeouts, failed loads, and cache hits cost nothing, and response headers identify the page verdict and whether the shot was billed. Its MCP server exposes take_screenshot, get_page_info, and capture_pdf for Claude, Cursor, and other MCP clients. The free plan includes 1,000 screenshots per month with no card; paid plans start at $5 for 3,000 shots. Create a free ScreenshotNeo account.

Short FAQ

Is IANA the same as the RFC?

No. IANA records the allocation and metadata; the referenced RFC defines protocol behavior.

Does an unassigned value mean I can use it?

No. It means no current assignment is recorded. Follow the applicable registration and experimentation rules.

What does CH mean in the TLS 1.3 column?

CH means ClientHello, the handshake message context listed by IANA.

Why are several registries on one page?

IANA groups related TLS namespaces for navigation. Their numbers and meanings remain separate.

How should I cite a lookup?

Include the live registry URL, exact row or codepoint, referenced RFC, and date checked.