view-distance vs simulation-distance, explained

Quick answer view-distance controls how far the server sends chunks to each player’s client. simulation-distance controls how far the server actually runs the world (mobs, redstone, crops, hoppers). Both default to 10. If your server is laggy, lower simulation-distance first; it is almost always the more expensive setting.

Why these two settings confuse people

Every Minecraft server has a server.properties file. It gets regenerated automatically the first time the server starts, and again every time you change a value, so the file in your server folder is always the current one [1].

Two of its settings look almost identical: view-distance and simulation-distance. Both are integer values measured in chunks. Both default to 10. Both control how much world exists around each player.

They are not the same setting. They control two completely different things, and they cost the server different amounts of work.

If you are tuning for lag, that difference is the whole game.

What `view-distance` actually does

view-distance sets how many chunks in every direction the server sends to each connected client. The default value is 10, and the valid range is 3 to 32 [1].

Think of it as the radius of the picture frame around each player. With view-distance=10, the client receives a 21 by 21 chunk grid (10 chunks out from the player in each direction, plus the chunk they stand in). With view-distance=8, they receive a 17 by 17 grid.

Chunk count grows with the square of the radius. Going from 10 to 12 does not add 20 percent more chunks. It goes from 441 to 625 per player, which is closer to 42 percent more data the server has to push out and the client has to keep in memory.

What it costs the server:

Network bandwidth per player
RAM on the client and, to a lesser degree, on the server
Disk reads as new chunks come into view

What it does not cost:

Tick time. Chunks within view distance but outside simulation distance are visible but frozen.

What `simulation-distance` actually does

simulation-distance controls how many chunks in every direction the server actually runs. Inside this radius, the game ticks: mobs pathfind, redstone updates, crops grow, hoppers move items, water flows. Outside this radius, the world is loaded but inert.

The default value is 10, valid range is 3 to 32 [1][2]. The setting was added to server.properties in Minecraft 1.18 (snapshot 21w38a) [1]. Before 1.18 there was no simulation distance; it was always equal to view distance.

From the Minecraft Wiki, exactly: “The maximum distance from players that living entities may be located in order to be updated by the server, measured in chunks in each direction of the player. If entities are outside of this radius, then they are not ticked by the server and they are not visible to players” [1].

What it costs the server:

Tick time, which is the single thing TPS measures
CPU on the main thread, because the Minecraft server tick is single-threaded
More entities to track, more block updates per tick

What it does not cost:

Player-visible view distance. Players still see whatever view-distance says.

The mental model that makes this easy

Three concentric rings around each player:

Inside simulation-distance: the world runs. This is where the lag comes from.
Between simulation-distance and view-distance: visible but frozen. Looks normal to players, costs the server nothing per tick.
Outside view-distance: not even visible to the player. Cheap to ignore.

This is why the common tuning view-distance=12, simulation-distance=7 (or similar) works. Players still see far. The server ticks a smaller circle. You keep the visual experience and shed the tick cost.

Which one should you lower first to fix lag?

Lower simulation-distance first. In almost every case, it is the more expensive of the two.

The reason is structural. view-distance mostly pays for bandwidth and client memory, both of which scale with player count but are bounded per player. simulation-distance pays for tick work, and tick work is what TPS measures and what players feel as lag.

A reasonable starting point if your server is stuttering with more than a handful of players online:

Player count	view-distance	simulation-distance
1 to 10	10	8
10 to 20	9	7
20 to 50	8	6
50+	6 to 8	4 to 6

These are starting values. The right number depends on what your players are doing (mob farms, redstone, spread-out exploration all cost more) and on the single-thread CPU performance of your host.

If you can only change one value today, change simulation-distance and restart the server. Then watch TPS for ten minutes before touching anything else.

How to change these settings on your server

Both settings live in server.properties in your server’s root directory. Edit with any plain text editor. Save. Restart the server. The settings only apply on startup.

Neither /viewdistance nor /simdistance is a vanilla command. A few client mods add commands like these for personal use, but they cannot change what a vanilla or Paper server actually sends or ticks. On a real server, server.properties (or Paper’s per-world config, covered below) is the only way to change these.

On most game panels the file is reachable from the file manager, and the panel’s “restart” button handles the reload. Restart cleanly (stop, then start), do not kill the process, so the world saves.

Common mistakes when tuning these settings

Raising view-distance to “improve quality” without checking tick budget. Chunks the player can see but the server is not ticking look fine, but they still consume bandwidth and server RAM for the cached chunk data. A jump from 10 to 16 pushes the chunk area from 441 to 1,089 per player, close to two and a half times as much.

Lowering view-distance to fix lag and seeing no improvement. That is the diagnosis telling you the lag is not view-distance, it is something else. Look at simulation-distance, then at entity counts, then at plugins.

Setting simulation-distance equal to view-distance because they “should match.” They do not need to match. They control different things. Many well-tuned servers run simulation-distance noticeably below view-distance on purpose.

Changing both at once. Change one, restart, watch TPS, change the next. Otherwise you cannot tell what helped and what hurt.

Forgetting to restart. server.properties is read on startup. Editing the file while the server is running does nothing until the next restart.

Quick FAQ

Does lowering simulation-distance break mob farms or redstone clocks? It can. Crops stop growing, mob spawns slow down, and redstone clocks stall outside the simulation radius. This is usually a feature on busy servers, but if your players rely on always-on farms, leave simulation-distance at the default.

Will my players notice if I lower simulation-distance? They will notice the world looking the same (view-distance unchanged) and the lag improving. They will not notice that mobs beyond the simulation ring are frozen, because those mobs were already invisible to them.

Is simulation-distance available in Bedrock? Not under that name. Bedrock’s server.properties has its own separate setting, tick-distance, which does a similar job: default 4, range 4 to 12 [1]. The Java values and key names in this post are for Java Edition specifically.

Does Paper or Spigot change the defaults? No. Paper and Spigot read the same server.properties file and keep these defaults. Paper does let you override simulation-distance on a true per-world basis, in a paper-world.yml file inside that specific world’s own folder [3], letting you run a lower value in the End than the Overworld, for example, but the server-wide defaults in paper-world-defaults.yml match vanilla unless you change them too.

Can I set different view-distance and simulation-distance per world? In vanilla, no, the values in server.properties apply to every world. Paper and Purpur let you override per world in their config files. If you are tuning a multi-world network or skyblock-style setup, look there instead.