What causes rubber-banding in multiplayer games?

A netcode reconciliation issue: the client predicts movement (to hide latency), the server corrects it to the authoritative position, and when the correction is large and applied abruptly, the entity snaps, rubber-bands. Large/frequent corrections come from inaccurate prediction, packet loss (the client drifts far before correcting), and high latency. Applying corrections as instant snaps makes any correction jarring.

How do I reduce rubber-banding?

Reduce the size and abruptness of corrections: improve prediction accuracy so the server's corrections are small and rare (predict using the same logic the server uses), smooth corrections by interpolating to the corrected position over a short time instead of snapping instantly, and handle packet loss so missed updates don't let the client drift far. Smoothing corrections especially makes rubber-banding gentle rather than jarring.

Why is rubber-banding worse on bad connections?

Because packet loss and high latency cause larger prediction errors: missed updates let the client drift further from the server before a correction arrives (producing a bigger snap), and more latency means more time for prediction and reality to diverge. This is expected, so make corrections more tolerant of poor conditions (smoothing them and handling packet loss) so even on a bad connection corrections are gentle rather than violent snaps.

Why Does My Multiplayer Game Rubber-Band?

Quick answer: Your multiplayer game rubber-bands because the client's predicted state and the server's authoritative state disagree and the correction is applied abruptly: the client predicts movement (to hide latency), the server corrects it, and when the correction is large and sudden, the entity snaps. Large corrections come from inaccurate prediction, packet loss (the client drifts far before correcting), and high latency.

Rubber-banding, that frustrating snap where a character jerks back to where they were a moment ago, is a hallmark of netcode problems. It happens when the client's predicted state and the server's authoritative state disagree and the disagreement is resolved abruptly. Reducing how often and how much they disagree, and smoothing corrections, is the fix.

Why Rubber-Banding Happens

In client-side prediction (used to hide latency), the client predicts movement immediately rather than waiting for the server. The server, as authority, computes the real result and sends corrections. Rubber-banding occurs when the server's correction differs significantly from the client's prediction and is applied abruptly, the entity snaps from the predicted position to the corrected one. The bigger and more sudden the correction, the worse the rubber-band.

Large/frequent corrections come from inaccurate prediction (the client predicts poorly, so the server frequently disagrees), packet loss (missed updates let the client drift far from the server before a correction arrives, producing a big snap), and high latency (more time for prediction and reality to diverge). Applying corrections as instant snaps makes any correction jarring.

How to Diagnose and Fix It

Rubber-banding is usually visible and reproducible, especially under simulated poor network conditions (added latency, packet loss). Determine whether it's driven by prediction error (corrections frequently large even on a good connection), packet loss (big snaps after missed updates), or abrupt correction application (any correction snaps). It correlates with network quality, worse on poor connections. Bugnet captures reports with context, so rubber-banding complaints and their correlation with connection quality surface.

Fix by reducing the size and abruptness of corrections: improve prediction accuracy (so corrections are small and rare), smooth corrections (interpolate to the corrected position over a short time instead of snapping), and handle packet loss (so the client doesn't drift far before correcting). See our guide on fixing rubber-banding.

Rubber-banding is a big, abrupt server correction of the client's prediction. Predict more accurately so corrections are small, and smooth them in instead of snapping, especially under packet loss.