TLS 1.3 Handshake Size Calculator

Pick a KEM and signature scheme, or load a preset. The page computes how many bytes the server sends on its first flight (ServerHello, certificate chain, CertificateVerify, Finished) and compares that total to three thresholds that decide whether the client gets everything in one round trip.

You will see three status chips. IW10 (14,600 B) is the default TCP initial congestion window from RFC 6928: a flight that fits inside it arrives in one round trip. IW20 (29,200 B) is the larger initial window that modern stacks and CDNs commonly use. QUIC 3x (3,600 B) is the anti-amplification limit in RFC 9000 section 8.1: a flight larger than three times the client's Initial packet pauses the server until the client acknowledges, adding a round trip. Each chip shows whether the current configuration fits the threshold and by how many bytes.

All math runs in your browser from published FIPS 203, 204, 205, and draft 206 primitive sizes. No network calls.

Load a configuration

Parameters

Key exchange (KEM) Leaf certificate signature Intermediate & root signature Used for every CA in the chain, including the off-wire root that signs the deepest intermediate. Chain depth (certs on wire) SCTs embedded in leaf OCSP staple attached

Server-to-client first flight

IW10 (14,600 B)-

IW20 (29,200 B)-

QUIC 3x (3,600 B)-

ClientHello key share	-
ServerHello key share	-
Certificate chain	-
CertificateVerify signature	-
OCSP staple	-
Server flight total	-
Packets at 1,460 B MSS	-

Per-certificate breakdown

What the thresholds mean

IW10 and IW20

TCP starts every connection with an initial congestion window. RFC 6928 fixed this at 10 segments (IW10 = 14,600 B at a 1,460 B MSS). Many modern stacks use an initial window of 20 segments (IW20 = 29,200 B). A server flight that fits inside IW10 reaches the client in one round trip. A flight that exceeds IW10 but fits IW20 depends on the stack. Exceeding IW20 guarantees at least one extra RTT of round-trip delay before the ACK allows the window to grow.

QUIC 3x amplification limit

RFC 9000 section 8.1 caps the server at sending no more than three times the bytes it has received from an unverified client address. A typical client Initial packet is ~1,200 B, so the server can send about 3,600 B before it has to pause for address validation. A PQC certificate chain that blows past that limit stalls the handshake waiting for a client ACK.

Chain depth and the root

TLS 1.3 servers send the leaf and intermediates. The root stays in the client trust store and is not on the wire. Even so, the root's signature scheme sets the sig field size of the deepest intermediate that is transmitted, which is why this calculator asks for a CA signature scheme.

Sources

NIST FIPS 203 (ML-KEM), August 2024, Table 2 for public key and ciphertext sizes.
NIST FIPS 204 (ML-DSA), August 2024, Table 1 for signature and public key sizes.
NIST FIPS 205 (SLH-DSA), August 2024, Table 1 for each parameter set.
NIST draft FIPS 206 (FN-DSA / Falcon). Signature size is variable. Published averages are used; real deployments see ±10% per signature.
RFC 5280 for X.509 / SubjectPublicKeyInfo DER framing of classical keys.
RFC 6928 (IW10), RFC 9000 section 8.1 (QUIC amplification), RFC 6962 (SCT sizes).
IETF draft-ietf-tls-hybrid-design for hybrid KEM share concatenation.

Numbers are estimates of the TLS record-layer bytes before encryption framing overhead. Real captures vary by a few hundred bytes depending on extension choice, OCSP response contents, cert subject length, and whether SCTs are stapled vs. embedded. Use this as a sizing tool, not a packet-level simulator.