Fast internet but Zoom or Teams keeps freezing? Fix the jitter

The short version

Jitter is when your internet's delay keeps changing from moment to moment instead of staying steady. Even with fast internet and a decent average ping, jitter is what makes voices break up and games stutter. The good news: the usual causes are Wi-Fi and a busy connection, and both are fixable.

What's actually happening

Think of cars arriving at a tollbooth. If a car arrives every 2 seconds, smooth and even, traffic flows. But if three cars arrive at once, then none for 10 seconds, then a clump again, you get chaos — even if the average is still one car every 2 seconds.

Your voice and game data travel as small packets that are supposed to arrive evenly spaced. Jitter is how much that spacing wobbles, measured in milliseconds (ms). Low, steady spacing sounds and feels smooth. Wobbly spacing sounds choppy, because your device has to guess what to play while it waits for the late packets.

Why it matters to you

• Calls sound robotic, clip words, or drop out for a second.
• Games rubber-band — your character jumps or snaps back.
• Live video freezes and un-freezes even though the speed test looks fine.
• A perfect average ping can still have bad jitter — which is why "fast" internet can still sound terrible.

How to measure it

1. Run this site's test and look for the jitter number (shown in ms).
2. As a rough guide: under 5 ms is excellent, under 20 ms is fine for calls and most games, and over 30 ms starts to cause problems.
3. Test once on Wi-Fi and once with a cable if you can — the difference tells you a lot.

How to fix it

Step 1: Use a cable (the biggest single fix)

Wi-Fi is the most common cause of jitter, because the air is shared and packets wait their turn unevenly. Plugging the device straight into the router with a network (Ethernet) cable usually smooths things out instantly.

• Computers: plug one end into the computer, the other into a numbered port on the router.
• PlayStation 5: Settings → Network → Settings → Set Up Internet Connection → Use a LAN Cable.
• Xbox Series X/S: plug in the cable; it uses wired automatically. Check in Settings → General → Network settings.
• Nintendo Switch: needs a USB Ethernet adapter, then System Settings → Internet → Wired Connection.

See the gear below for cable tips.

Step 2: If you must use Wi-Fi

1. Move closer to the router and use the 5 GHz network.
2. Keep microwaves, baby monitors, and lots of other devices from clogging the air during calls.
3. Restart the router and modem (unplug 30 seconds; modem first, then router).

Step 3: Calm a busy connection

Jitter often spikes when the house is busy (someone uploading, a backup running). A router feature called QoS or Smart Queue Management keeps the spacing even under load:

• ASUS: router.asus.com → Adaptive QoS (newer: Adaptive QoE) → turn on.
• Netgear: routerlogin.net → Dynamic QoS → Enable and enter your speed.
• TP-Link: Tether app → HomeShield/HomeCare → QoS.
• eero / Google Nest Wifi: managed automatically.

What won't help

Buying a faster plan rarely fixes jitter — jitter is about evenness, not amount. If your connection genuinely can't deliver steady packets even wired and idle, the cause is usually a line fault (see the packet loss guide) or something outside your home.

How to check it worked

Run the test again after each change, ideally during a real call or game. You want a low jitter number that stays low, especially while the connection is busy. If wired is smooth but Wi-Fi still wobbles, keep important calls and games on the cable.

If your result was already good

If your jitter was already low, you're set — no changes or purchases needed. Keep router firmware updated and, for the things that really matter like big meetings or ranked games, a wired connection keeps jitter low with no effort. Re-check if you change providers or switch to satellite/fixed-wireless internet.

Want to go further?

The Advanced version explains jitter buffers, how to measure variance properly, Wi-Fi airtime effects, and when jitter points to a physical-layer fault versus a queueing problem.

Is this your problem?

People usually land here after searching for one of these, and they all point back to jitter (unstable timing) or packet loss:

• "Rubberbanding" in a game — your character snaps back or teleports in CS2, Rust, Battlefield 6, Minecraft or Dead by Daylight. That stutter is almost always jitter or loss, not raw ping.
• "Fast internet but still lagging." Your speed test looks great, yet matches feel choppy. Bandwidth and jitter are different things: a 500 Mbps line with unstable timing still rubberbands.
• Teams says "poor call quality was caused by the network." That is Microsoft's way of reporting jitter and loss on your connection. The three numbers to check are jitter, packet loss and loaded latency.
• "How to fix jitter on ethernet." Being wired rules out Wi-Fi interference, which usually points at a bad cable, a failing port, or your router buffering under load.

Summary

Jitter is the variation in packet delay (inter-arrival or RTT variance), not delay itself. It degrades real-time media because receivers must buffer to a worst-case spacing; excess jitter forces either added latency (deeper jitter buffer) or discarded late packets (dropouts). The two dominant home causes are Wi-Fi airtime contention and queueing variance under load; a third, less common cause is physical-layer errors forcing retransmits. Fix in that order.

What jitter actually is

Formally, jitter is the statistical dispersion of packet delay. RFC 3550 (RTP) defines an interarrival jitter estimate as a smoothed mean deviation of the transit-time difference between consecutive packets. In practice you care about the distribution's tail: a low mean with a fat P99 still produces audible artifacts, because a receiver's de-jitter buffer sizes to near the worst case it tolerates. Beyond that bound, packets arrive "too late to play" and are dropped — functionally identical to packet loss for the user.

Why it breaks real-time media

VoIP and game netcode assume roughly isochronous delivery. A de-jitter buffer trades latency for smoothness: a 50 ms buffer hides 50 ms of jitter but adds 50 ms of mouth-to-ear delay. Adaptive buffers grow under jitter, which is why a jittery call feels both choppy and laggy. Codecs with packet-loss concealment mask small gaps; sustained jitter overwhelms concealment and you hear robotic/warbling audio.

Measure it properly

• Continuous RTT variance: ping -n 200 1.1.1.1 (Windows) or ping -c 200 1.1.1.1 (macOS/Linux); read max-min spread and, on Unix, mdev. A tight cluster with occasional large spikes is the classic Wi-Fi/queueing signature.
• mtr (mtr -rwzbc 200 1.1.1.1) shows per-hop jitter (StDev) and loss together — best for localizing where variance enters the path.
• Idle vs loaded: capture both. Jitter that appears only under load is queueing jitter (bufferbloat-adjacent) and responds to SQM. Jitter present even at idle, wired, points to the access link or Wi-Fi RF.
• Per-application: client call stats (Teams/Zoom/WebRTC chrome://webrtc-internals) report jitter and buffer size directly — use them to confirm user-visible impact, not just ICMP.

Localize and fix

Wi-Fi (most common)

802.11 is half-duplex and contention-based; CSMA/CA, retransmits, rate adaptation, and competing stations make inter-arrival spacing inherently variable. Mitigations:

• Wire the endpoint. Ethernet removes airtime contention and retransmit jitter — the single most effective fix. For consoles use the wired path (PS5: "Use a LAN Cable"; Xbox auto-selects wired; Switch needs a USB-Ethernet adapter).
• If wireless is unavoidable: 5/6 GHz, a clean channel, 80 MHz width where spectrum allows, strong RSSI (>-65 dBm), and WMM enabled. Isolate legacy 802.11n/g clients that drag down airtime. Disable aggressive client power-save for real-time use.

Queueing under load

Bulk flows filling an unmanaged buffer add variable queueing delay. Deploy SQM — CAKE (preferred) or fq_codel — shaped to ~90% of line rate. Flow isolation gives real-time flows their own queue, collapsing loaded jitter. ASUS: Adaptive QoS/QoE, or ASUSWRT-Merlin for cake; OpenWrt luci-app-sqm; pfSense/OPNsense limiters with fq_codel. Enable ECN to reduce drops.

Physical-layer / access faults

If jitter is high even idle and wired, suspect L1. On DOCSIS, read the modem status page: downstream SNR/MER (want 35 dB+ for 256-QAM), upstream power (under ~50 dBmV), and FEC uncorrectable error counts — rising uncorrectables across channels indicate ingress noise causing retransmits and variable delay. On DSL, watch for low SNR margin and errored seconds. These are ISP/plant issues; document and escalate.

Verify

Re-measure idle and loaded, wired and wireless. Targets: jitter under ~5 ms wired idle, under ~20 ms is comfortable for VoIP/gaming, and — critically — no large increase under load. Confirm with the application's own jitter/buffer stats during a live session, since ICMP jitter and media jitter can diverge when traffic is shaped. Keep a before/after mtr report as evidence.

Edge cases & gotchas

• Late packets = loss to the codec: reducing jitter can cut apparent "loss" without any change to actual drop rate.
• Jitter buffer tradeoff: fixing jitter may let you shrink buffers and reduce latency — a double win for interactive apps.
• Mesh wireless backhaul adds a second contention domain and often injects jitter; prefer wired backhaul between mesh nodes.
• Powerline adapters are jitter-prone under electrical noise; Ethernet or MoCA is steadier.
• Interference sources (microwaves, USB 3.0 radiating into 2.4 GHz, dense neighbor APs) produce bursty jitter that looks intermittent — survey the RF environment before blaming the ISP.

Reading the jitter distribution

A mean jitter figure hides the behavior that matters. What breaks media is the tail and the burstiness: a stream can show 3 ms mean jitter yet drop audio because once a second a clump of packets arrives 60 ms late. Pull per-packet transit times rather than a summary — chrome://webrtc-internals graphs jitter, jitter-buffer delay, and discarded-late packets over time for any WebRTC call, and softphones expose MOS and jitter in their diagnostics. Correlate a spike in discarded-late packets with a spike in RTT variance from a concurrent mtr run to prove the jitter is network-induced rather than a CPU/audio-driver stall on the endpoint.

Wi-Fi airtime, quantified

Because 802.11 is a shared half-duplex medium with CSMA/CA backoff, every retransmit and every competing station adds a variable wait before your frame transmits. A single sticky, far-away client transmitting at a low MCS consumes disproportionate airtime (the "performance anomaly" of rate-diverse BSSes), inflating jitter for everyone on that radio. Mitigations that measurably help: airtime fairness (OpenWrt and modern ASUS/Broadcom drivers enable it), band steering legacy clients off the fast radio, WMM/QoS for the voice access category, and reducing channel width in a congested band so fewer retransmits occur. None of these match the determinism of a wired link, which is why wiring the one latency-sensitive device beats tuning the RF for it.