MTU / MSS & Fragmentation Calculator
Work out the real MSS once tunnels and headers have taken their cut.
What you provide
Timestamps take 12 bytes and are on by default on Linux and macOS. Set 0 to see the textbook figure.
Result
MSS 1448 bytes on a 1500 byte MTU
An MSS of 1448 leaves 97% of each frame carrying real data. If you are troubleshooting rather than planning, test the real path MTU directly by pinging with the do-not-fragment flag set and shrinking the payload until it gets through. The largest size that succeeds, plus 28 bytes for the probe and IP headers, is the actual path MTU.
- Interface MTU
- 1500 bytes
- IPv4 header
- −20 bytes
- TCP header20 base plus 12 of options
- −32 bytes
- Maximum segment size
- 1448 bytes
- Payload efficiency
- 96.5%
- Fragmentation risk
- low
What this cannot tell you
- Header arithmetic on the values you choose. It does not probe a path or measure the MTU your traffic actually gets.
- Encapsulation overheads vary with cipher and mode, particularly for IPsec. The figures here are typical rather than exact for every configuration.
Take this with you
How this calculation works
The familiar 1460 byte MSS comes from a 1500 byte Ethernet MTU minus 20 bytes of IPv4 header and 20 of TCP header. Everything added underneath takes more: PPPoE takes 8 bytes, a GRE tunnel 24, WireGuard about 60, and IPsec anywhere from 37 to over 100 depending on mode. TCP timestamps take another 12 bytes of options and are enabled by default on most systems. This subtracts each layer in turn and flags the case where the result is small enough to cause trouble for traffic passing through.
What the results mean
- Maximum segment size
- The largest TCP payload that fits in one packet without fragmenting. This is the number to clamp to on a router when a tunnel is involved.
- Payload efficiency
- The share of each frame carrying real data. Heavy encapsulation on a small MTU can spend a fifth of the link on headers.
- Fragmentation risk
- Flagged when encapsulation pushes the usable MTU below the 1500 bytes the rest of the internet assumes. This is where black-hole faults come from.
Common problems and fixes
- Small pages load but large transfers and TLS handshakes hang
- This is the signature of an MTU black hole. Path MTU discovery depends on fragmentation-needed control messages reaching the sender, and a firewall that drops those messages breaks it silently. The sender keeps retransmitting full-size packets that the tunnel cannot forward. Clamp MSS on the router that owns the tunnel, and allow the fragmentation-needed control message, type 3 code 4, through every firewall in the path.
- A VPN works for some sites and not others
- Same cause, seen from the other side. Sites that happen to advertise a smaller MSS or send smaller responses work; those that fill packets do not. Clamp MSS on the tunnel interface rather than trying to fix it per site. On Linux this is a single iptables or nftables rule that clamps to the path MTU.
Frequently asked questions
How do I find the real path MTU?
Ping with the do-not-fragment flag set and shrink the payload until packets get through. On Windows the flag is -f with -l for size, on Linux it is -M do with -s. Take the largest payload that succeeds and add 28 bytes for the probe and IP headers to get the path MTU.
Should I lower the MTU or clamp the MSS?
Clamp MSS where you can. Lowering the interface MTU affects every protocol including UDP and reduces efficiency for traffic that never needed it. MSS clamping only touches TCP sessions crossing that interface, which is where the problem actually is, and it works even when the endpoints ignore path MTU discovery.
Do jumbo frames help?
Inside a data centre or a storage network where every device on the path agrees, yes, meaningfully. Across the internet, no. A single hop that does not support 9000 bytes will either fragment or drop, and you cannot control what every hop supports. Jumbo frames are a local optimisation, not an end-to-end one.
Put this on your own site
Free to embed, no attribution required beyond the source link the frame carries itself. It runs entirely in your visitor's browser, sets no cookies and loads no third-party script.
<iframe src="https://runthetests.com/embed/mtu-mss-calculator/" width="100%" height="560" style="border:1px solid #e5e5e5;border-radius:8px" title="MTU / MSS & Fragmentation Calculator" loading="lazy"></iframe>
Preview it at https://runthetests.com/embed/mtu-mss-calculator/. Embedded pages are marked noindex, so yours stays the canonical copy — not this one.