If you price Minecraft server hosting, bandwidth is the silent variable. Players ask fair questions: how much bandwidth does a Minecraft server use, what Minecraft server bandwidth usage per player looks like in the real world, and whether their home connection can survive a birthday party spike. This guide explains Minecraft server network requirements in plain terms: averages, spikes, and the difference between bandwidth and latency.
Quick answer: plan for about 50 to 100 KB/s of upload per active player on a vanilla or light Paper server. That is 400 to 800 kbps, or 0.4 to 0.8 Mbps. If a player kept that rate for a full hour, it would come to 180 to 360 MB per hour. For modded servers, plan for 100 to 200 KB/s. These are planning estimates: Mojang publishes no official per-player figure, so measure your own busy hour once the server runs.
Bandwidth versus latency: two different problems
Bandwidth is how much data you can move per second. Latency is how long a packet takes to travel. Minecraft feels "laggy" when latency jumps or when the server cannot keep up with simulation, not only when bandwidth is low.
That said, insufficient upload on the host side creates packet loss and rubber-banding that looks like latency. You need enough headroom for bursts, especially when many players load chunks at once.
Typical Minecraft server bandwidth usage per player
These are planning estimates, not measurements and not guarantees. There is no official Mojang number, and modpacks, view distance, entity counts, and plugins can multiply traffic. This guide uses one range throughout, so every sum below starts from the same numbers.
Vanilla or light Paper servers
Plan for 50 to 100 KB/s per active player upstream from the server toward clients when players are moving, loading chunks, and interacting. That is 400 to 800 kbps, or 0.4 to 0.8 Mbps. Idle players in a small area consume less. World tours and elytra flights consume more.
Modded servers
Modded clients sync extra data: machines, GUIs, custom entities, and sometimes chatty networking from mods. Plan for 100 to 200 KB/s per active player (0.8 to 1.6 Mbps), with heavy packs trending higher during exploration or in large bases.
Why the range is wide
Minecraft networking is bursty. A player standing AFK in a void farm is not the same as twenty players spreading across fresh terrain after a reset. Always plan for peaks, not averages alone.
Mbps, MB/s and MB per hour: converting the numbers
Most bandwidth mistakes are unit mistakes. Internet plans and speed tests quote megabits per second (Mbps). Download windows and many graphs show bytes per second (KB/s or MB/s). A byte is 8 bits, so:
- 1 MB/s = 8 Mbps, and 1 KB/s = 8 kbps
- Mbps = KB/s x 8 / 1000
- MB per hour = kbps x 3600 / 8 / 1000, which is the same as KB/s x 3.6
A home connection with 10 Mbps upload can therefore send 1.25 MB/s, not 10 MB/s.
| Per active player | KB/s | kbps | Mbps | MB per hour |
|---|---|---|---|---|
| Vanilla, low end | 50 | 400 | 0.4 | 180 |
| Vanilla, high end | 100 | 800 | 0.8 | 360 |
| Modded, low end | 100 | 800 | 0.8 | 360 |
| Modded, high end | 200 | 1,600 | 1.6 | 720 |
The sum for the vanilla high end: 800 kbps x 3600 seconds = 2,880,000 kilobits per hour. Divided by 8 that is 360,000 KB, and divided by 1000 it is 360 MB. The MB per hour column assumes the player keeps the rate for the whole hour, so read it as a ceiling: an hour spent building in one base uses less.
This guide uses decimal units (1 KB = 1000 bytes). Tools that count in KiB (1024 bytes) show numbers about 2.4 percent different, which does not change any decision.
Monthly data estimates from per-second rates
You can turn the hourly figure into a monthly total:
monthly MB = MB per hour x players x hours online per day x 30
- A flat 100 KB/s for one player all month: 100 KB/s x 86,400 seconds x 30 days = 259,200,000 KB, about 259 GB. Nobody sustains a peak rate around the clock, which is why a flat rate overstates real use.
- Five friends who each play two hours a day: 5 x 2 x 30 = 300 player hours. At 180 to 360 MB per hour that is 54,000 to 108,000 MB, so 54 to 108 GB as a planning ceiling for the month.
A more practical approach for hosts:
- Measure a busy hour with network graphs on your hypervisor or panel
- Extrapolate to your billing period with a safety margin for events
On a VPS, our guide to estimating VPS bandwidth shows how to measure that busy hour with vnStat and turn the rate into a monthly total.
If you run events ("everyone log in at 8 p.m."), your peak defines port requirements more than your Tuesday afternoon graph.
Factors that increase bandwidth usage
View distance and simulation distance
Higher distances mean more chunks sent, more block updates, and more entities in range. The theme is consistent: more loaded world equals more data movement. The exact settings and their defaults are in the table in the next section.
Entity-heavy areas
Farms, item entities, minecarts, and complex redstone can increase update traffic. Plugins that sync holograms or particle effects add overhead.
Plugins and proxies
Badly written plugins can spam plugin messages. Proxies add overhead but also help you split networks; internal traffic between backend and proxy must be counted on the datacenter link.
World generation and exploration
New terrain generation produces chunk data clients have never cached. Reset worlds and large border expansions create bandwidth spikes.
Settings that change server traffic
These settings decide how much world and entity data the server pushes to each player, and how fast. The defaults and descriptions come from the Minecraft Wiki's server.properties page and Paper's global configuration reference, both read on 4 November 2026.
| Setting | File | Default | What the docs say | What it means for traffic |
|---|---|---|---|---|
view-distance | server.properties | 10 (range 3 to 32) | "The amount of world data the server sends the client", in chunks in each direction of the player | The main lever: a lower value sends fewer chunks on joins, teleports and while moving |
simulation-distance | server.properties | 10 (range 3 to 32) | Living entities outside this radius are not ticked by the server and are not visible to players | A lower value leaves fewer entities to update and send |
entity-broadcast-range-percentage | server.properties | 100 (range 10 to 1000) | "How close entities need to be to the player to be sent"; 50 sends them at half the usual distance | A lower value sends entities only when they are closer to the player |
network-compression-threshold | server.properties | 256 (bytes) | Packets of this many bytes or more are compressed; -1 disables compression, 0 compresses everything | -1 sends every packet uncompressed, so traffic goes up; 0 also compresses tiny packets, which the wiki notes can come out larger than the source |
chunk-loading-basic.player-max-chunk-send-rate | config/paper-global.yml (Paper only) | 75 | "The maximum rate in chunks per second that the server will send to any individual player"; -1 disables the limit | Caps the burst per player: a join or a flight is spread over more seconds, but the total stays the same |
Two notes. The server's view-distance is the upper limit for what players receive: the wiki describes the client's render distance as something players can customize "so long as it's under the server's setting". And of the five settings, only the Paper send rate leaves the total amount of data unchanged, because it limits speed rather than distance; the other four change how much the server sends.
You can set the server.properties keys with our server.properties generator. On a Paper server, including our PaperMC hosting, the send rate lives in config/paper-global.yml under chunk-loading-basic.
Upload versus download on the server
Your server's upload to the internet is usually the constraint for player experience. The server sends world updates to many clients. Downloads from the server's perspective (client-to-server packets) matter too, especially for chatty mods, but upload headroom is the classic home-hosting failure point.
On a VPS or dedicated host in a datacenter, symmetric or high-upload commercial links remove the asymmetry pain of residential ISP plans.
Is a 1 Gbps port enough?
For most Minecraft communities, yes, a 1 Gbps port is ample if it is not oversubscribed in secret ways. At the vanilla estimate's high end of 0.8 Mbps per player, even 200 active players add up to 160 Mbps. Thousand-player networks are architectural problems before they are raw bitrate problems.
What matters more than the sticker:
- Sustained throughput under load without aggressive shaping
- Packet loss during bursts
- DDoS resilience on UDP-heavy attack patterns relevant to games
If you ever approach sustained hundreds of Mbps on Minecraft, you are usually doing something unusual (massive file transfers, misconfigured plugins, or a tunnel mislabeled as game traffic).
Latency optimization that is not "more bandwidth"
Host near your players
Pick a region that matches your community. For a group spread across Europe, a Western European location keeps the distance short for most players. Our Minecraft server hosting has nine regions: the Netherlands, Germany, Poland, Canada, California, Virginia, Singapore, India and Australia.
Tune server settings
Reduce unnecessary work per tick, optimize plugins, and pre-generate worlds for public survival servers when appropriate.
Use wired monitoring
Watch TPS, ping, and network discard counters. Bandwidth graphs alone miss micro-bursts that hurt interactability.
Ask your host how traffic is counted
Players worry about surprise bills when a clip goes viral or a weekend event doubles concurrent users. Before you pick a host, ask how traffic is counted: is there a monthly transfer allowance, what happens when you go past it, and does attack traffic count toward it. Get the answer in writing instead of relying on a vague promise on a sales page.
Whatever the policy, a big allowance does not fix a slow server. You still want sensible architecture, DDoS protection, and hardware that matches your player count.
Practical measurement checklist
- Graph five-minute peaks, not only daily averages
- Test event loads with volunteers before marketing a launch
- Log plugin updates that coincide with traffic changes
- Compare regions if you have a split player base
- Document baseline after optimization so regressions are obvious
Worked example: thinking in megabits for a medium community
Suppose you budget the top of the vanilla range, 100 KB/s per player upstream during a busy moment, for a mod-light Paper server. 100 KB/s x 8 = 800 kbps, or 0.8 Mbps per player. Twenty simultaneous explorers therefore need 20 x 0.8 = 16 Mbps of game traffic before overhead. If they kept that up for a full hour, the server would send 20 x 360 MB = 7,200 MB, about 7.2 GB.
Add voice communities, Discord bots, and backup jobs on the same machine, and you see why "I have 100 Mbps upload" on paper does not mean 100 Mbps available to Minecraft at 8 p.m. Separating backup traffic, using off-host backups, and scheduling heavy jobs outside peak hours keeps game traffic smooth.
Provider networking: what fine print actually means
Some hosts advertise big ports but apply fair use policies that throttle sustained loads. Others share uplinks aggressively. Ask direct questions: is the port dedicated to your hypervisor slice, what happens during volumetric attacks, and do they publish typical packet loss metrics.
For Minecraft server network requirements, the operational truth is more about low packet loss and stable routes than about a flashy number on a sales page. A stable 250 Mbps with honest capacity beats a "10 Gbps" label on an oversubscribed neighbor.
When CDN thinking misleads Minecraft operators
Content delivery networks help websites. Minecraft is a long-lived, stateful TCP and occasional UDP ecosystem that does not magically become a CDN problem. You optimize the server location, simulation cost, and network path, not cache headers.
Troubleshooting symptoms that look like bandwidth issues
If players complain about "lag," split the diagnosis carefully. Uniform high ping to the server often means distance or routing. Rubber-banding with good ping can mean TPS problems. Stutter that correlates with backup jobs points to disk or uplink saturation on the host. Correlated spikes after a plugin update points to software.
Capture a short window of server tick time, network counters, and CPU wait together. Single-metric debugging sends you chasing the wrong knob, especially when Minecraft server bandwidth usage per player is only one slice of the full story.
FAQ
How much bandwidth does a Minecraft server use with 50 players?
At the planning estimate of 0.4 to 0.8 Mbps per active player, 50 active players need about 20 to 40 Mbps of upload on a vanilla-style server (50 x 0.4 and 50 x 0.8), and roughly twice that on a modded one. Measure your actual peak during a busy window and replace the estimate with it.
How much data does Minecraft multiplayer use per hour?
About 180 to 360 MB per hour per player at the vanilla planning estimate of 50 to 100 KB/s, and 360 to 720 MB on a modded server. Those are ceilings for a player who keeps moving and loading chunks; an hour spent building in one place uses less. What the server sends a player is what that player's client downloads, so the same figures work if you play on a capped connection.
Does bandwidth usage scale linearly with player count?
Mostly, but not perfectly. Ten players in one chunk is cheaper than ten players spread across fresh terrain. Peaks are superlinear during exploration.
Is low ping possible without huge bandwidth?
Yes. Latency is dominated by routing and distance. Bandwidth helps avoid congestion-related delays, but replacing a bad route with a closer region often matters more.
Why does my home-hosted server rubber-band at night?
Residential upload saturates, bufferbloat appears, and packets arrive late. A small VPS with clean upstream often beats a strong CPU on a weak home uplink.
What network requirements should I put in a Minecraft server listing?
List region, expected ping to major cities, anti-cheat policy, and whether you use a proxy. Honest expectations reduce churn more than buzzwords.
Bandwidth per player at a glance
There is no single official Mojang number for Minecraft server bandwidth per player that stays accurate for every version, view distance, modpack, plugin stack, entity count, and player behavior. Treat per-player bandwidth as an estimate, then measure your real server with network graphs.
| What you want to know | Answer |
|---|---|
| Bandwidth per player | Plan for 50 to 100 KB/s of upload per active player on vanilla or light Paper and 100 to 200 KB/s on modded, with spikes during chunk loading, map exploration, teleports, joins, and modded content. |
| Bandwidth per player in kbps | 400 to 800 kbps (0.4 to 0.8 Mbps) per active player on vanilla, 800 to 1,600 kbps on modded. A planning estimate, not an official cap. |
| Data per player per hour | At most 180 to 360 MB per hour on vanilla if the player keeps that rate all hour (kbps x 3600 / 8 / 1000). Hours with idle time use less. |
| Bandwidth per player on PaperMC | Paper does not set one fixed number. Its player-max-chunk-send-rate (default 75 chunks per second) caps how fast chunks go to each player; view distance, simulation distance, and player movement still decide how much. |
| Multiplayer data use per hour for the player | The same 180 to 360 MB per hour ceiling, because what the server sends is what the client downloads. Usually modest compared with video streaming, but high view distance, maps, or mods push it up. |
For hosting, bandwidth usually matters less than latency, packet loss, and route quality until the server becomes large. A 1 Gbps port is plenty for most Minecraft servers if the CPU and tick rate are healthy.
Sources
All opened on 4 November 2026:
- Minecraft Wiki: server.properties (view-distance, simulation-distance, entity-broadcast-range-percentage and network-compression-threshold: defaults, ranges and descriptions)
- PaperMC documentation: Global configuration (config/paper-global.yml and chunk-loading-basic.player-max-chunk-send-rate)