Source: https://gameye.com/glossary/hitbox/ --- title: "Hitbox | Gameye" description: "A hitbox is the invisible collision shape on a character that determines whether an attack or bullet registers as a hit." --- # 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](https://gameye.com/glossary/lag-compensation/) · [Authoritative Server](https://gameye.com/glossary/authoritative-server/) · [Tick Rate](https://gameye.com/glossary/tick-rate/) · [Netcode](https://gameye.com/glossary/netcode/) Building a multiplayer game? Gameye hosts dedicated game servers: ship your server as a Docker container and start one per match with a single API call, in a region near your players. [See how it works →](https://gameye.com/how-it-works/) [Back to Glossary](https://gameye.com/glossary/) ## Related terms - ### Lag Compensation Lag compensation rewinds server game state to the moment a player fired, judging shots fairly despite network delay. [Read more](https://gameye.com/glossary/lag-compensation/) - ### Authoritative Server An authoritative server runs your game logic and determines match truth — no client can override it, making cheating structurally impossible. [Read more](https://gameye.com/glossary/authoritative-server/) - ### Tick rate Tick rate is how many times per second a game server updates the game state, measured in hertz (Hz). A 64-tick server updates 64 times a second; a 128-tick server, 128. [Read more](https://gameye.com/glossary/tick-rate/) - ### Netcode Netcode synchronises game state between players. Poor netcode causes lag, rubber-banding, and hit registration issues in multiplayer games. [Read more](https://gameye.com/glossary/netcode/) - ### Client-Side Prediction Client-side prediction applies player inputs locally without waiting for the server, so movement feels instant even on high-latency connections. [Read more](https://gameye.com/glossary/client-side-prediction/)