MTU / MSS Calculator

MTU and MSS, and why they're not the same number

MTU (Maximum Transmission Unit) is the largest IP packet a link can carry in one piece, including the IP header. MSS (Maximum Segment Size) is the largest chunk of TCP payload a single segment can carry — it's what's left over after subtracting the IP header (20 bytes for IPv4, 40 for IPv6) and the TCP header (20 bytes, plus 12 more if the connection negotiates TCP timestamps, which most modern stacks do by default). The two numbers get confused constantly because they're both "the packet size limit," but an MSS advertised without accounting for every layer between the two TCP endpoints is a very specific and very common bug: connections establish fine, small requests work, and then a large response or file upload stalls or hangs entirely.

The reason it's specifically the large transfers that break is Path MTU Discovery. TCP starts by assuming the interface MTU is usable end to end and relies on ICMP "fragmentation needed" (IPv4) or "packet too big" (IPv6) messages to discover a smaller MTU somewhere on the path. Firewalls and security groups block ICMP by default astonishingly often, which silently disables PMTUD — the segment that's too large just vanishes with no signal back to either endpoint, and the connection hangs until it times out. TCP MSS clamping avoids the whole failure mode by never advertising an MSS large enough to need mid-path fragmentation, regardless of whether ICMP gets through.

Why stacking is the part every other calculator skips

A single-layer calculator answers "what's my MTU under WireGuard" or "what's my MTU under GRE," but production topologies rarely stop at one tunnel. A remote worker's laptop might run WireGuard over a PPPoE/DSL uplink that's already 8 bytes short of standard Ethernet. A cloud-to-cloud connection might carry VXLAN-encapsulated overlay traffic inside an IPsec tunnel between two VPC gateways, each layer eating into the same 1500-byte (or smaller) budget. Each encapsulation subtracts its own header from whatever MTU survived the layer above it — the math is cumulative, not a pick-one lookup — and the only way to get a correct effective MTU is to sum every layer the packet actually crosses on the wire, in the right order. That's the entire reason this tool lets you build an ordered stack instead of a single dropdown.

Measuring the real path MTU instead of estimating it

This calculator computes what your effective MTU should be given a base link MTU and a known encapsulation stack — but the only way to confirm what a path actually supports is to test it with a fragmentation-forbidding ping and binary-search the packet size:

• Linux: ping -M do -s <size> <host> — -M do forbids fragmentation, so a size that's too large fails outright instead of silently fragmenting.
• Windows: ping -f -l <size> <host> — -f sets the don't-fragment flag.
• macOS: ping -D -s <size> <host> — -D is the don't-fragment equivalent.

On every platform, the size you pass is the ICMP payload, not the full packet — you need to add 28 bytes back (8 bytes of ICMP header + 20 bytes of IPv4 header) to get the actual path MTU. So if ping -M do -s 1472 host succeeds but -s 1473 fails, the path MTU is 1472 + 28 = 1500. Compare that measured number against what this calculator predicts for your encapsulation stack — a mismatch usually means either an assumption about the stack is wrong, or there's a hop in the middle enforcing a smaller MTU than any endpoint is configured for.