Hitbox
A hitbox is the invisible collision shape attached to a game character or object that determines whether an attack, bullet, or ability registers as a hit. Hitboxes are simpler than the visible character model, trading visual precision for computational efficiency.
Players encounter hitboxes when a shot that visually appeared to miss registers as a hit, or a shot that appeared to connect does nothing. Both outcomes are attributable to hitboxes — and both have legitimate technical causes that go beyond “the game is broken.”
Hitboxes vs. hurtboxes
In fighting game terminology, these are distinct concepts. A hitbox is the area that deals damage — the active zone of an attack. A hurtbox is the area that receives damage — the part of a character that can be hit.
In shooter games, the same term covers both: the region on a character model that when intersected by a projectile or ray counts as a hit. Studios sometimes subdivide this into zones — head, torso, limbs — each with different damage multipliers.
Why hitboxes do not perfectly match the model
Precise per-polygon collision detection against a skinned, animated character model is computationally expensive. A fully animated human character may have tens of thousands of polygons changing position every frame. Checking whether a projectile intersects any of them, for every shot, on every server running dozens of simultaneous matches, would be prohibitively costly.
Instead, hitboxes approximate the character with simple geometric shapes — capsules, spheres, and boxes — that are fast to compute against. A standing player might be represented as a capsule covering the torso and a sphere at the head. These shapes track the character’s skeleton but do not exactly follow every animation. The tradeoff is intentional: slightly imprecise but fast enough to run on a server handling 64 players at 128 ticks per second.
Hitboxes and lag compensation
The most common cause of “I should have hit that” is lag compensation interacting with hitboxes. Here is what happens:
- You aim at an enemy on your screen.
- Your client is rendering the enemy slightly in the past due to interpolation.
- You fire. The input arrives at the server with your timestamp.
- The server rewinds the enemy’s hitbox position to match what you saw.
- The shot is evaluated against that historical hitbox position.
If lag compensation is working correctly, a shot that looked like a hit on your screen registers as a hit on the server. If compensation is tuned poorly, or the server’s historical records are imprecise, the rewound hitbox position may not match what the client rendered and the shot misses despite looking correct.
This is why hitbox complaints are almost always entangled with lag compensation complaints — the two systems interact directly, and a problem in one manifests as the other.
Server-side vs. client-side hit detection
Server-side hit detection is the standard for competitive multiplayer. The authoritative server validates every hit. Cheating requires compromising the server, which a player cannot do. The downside is that network latency introduces the mismatch described above, which lag compensation attempts to address.
Client-side hit detection lets the client report its own hits to the server, which trusts them. This eliminates lag compensation complexity but opens the door to aimbots and hit-registration cheats that simply tell the server every shot is a hit. Used only in games where anti-cheat is not a concern, or for specific low-priority hit types.
Hitbox visualisation and debugging
Most game engines provide a hitbox visualisation mode — a debug view that renders the collision shapes over the character model. This is the first tool used when investigating “the hitboxes feel off” complaints. Comparing the visible collision shape against the character’s animated pose often immediately reveals gaps between what players see and what the server evaluates.
See also: Lag Compensation · Authoritative Server · Tick Rate · Netcode