How Hitboxes Work In Video Games

The character model you see swinging a sword is not what the game checks to determine whether the sword connected. Underneath every visible character sits an invisible, simplified shape, usually a box, capsule, or sphere, that the engine actually tests for overlap. That invisible shape, the hitbox, is why a sword swing can visually miss an enemy by inches and still register a hit, or visually connect and still whiff. Understanding how these shapes work explains most of the "that should have hit" frustration in any game built around melee, ranged, or projectile combat.

Why games don't check pixel-perfect collision

Testing whether two complex 3D character meshes, each built from thousands of polygons, actually intersect on every single frame is computationally expensive. A detailed character model in a modern game can easily contain 20,000 to 100,000 triangles, and checking every triangle on one character against every triangle on another, dozens of times per second, for every character in a match, would consume far more processing power than almost any other part of the game combined.

So engines cheat, deliberately and openly. Instead of testing the real mesh, they attach simplified geometric shapes to characters and weapons: axis-aligned bounding boxes (AABBs, boxes that never rotate and are always aligned to the world's X, Y, and Z axes), oriented bounding boxes (boxes that can rotate with the character), capsules (a cylinder with rounded caps on each end), or spheres. Testing whether two boxes overlap is a handful of numeric comparisons. Testing whether two rotating meshes overlap polygon by polygon can be thousands of times more expensive for the same pair of objects.

This tradeoff is not unique to games. It is the same logic behind why a spell-checker compares words against a dictionary list instead of parsing full grammatical meaning, or why a metal detector reads a simple field disturbance instead of trying to identify the exact shape of what set it off. In both cases, a cheap, approximate check that runs constantly beats an expensive, precise check that would be too slow to use in real time. Hit detection in games works the same way: a fast approximation that runs every frame beats a perfect one that could never keep up with 60 or more frames per second.

Hitboxes versus hurtboxes: two different shapes doing two different jobs

Fighting games, shooters, and action games typically separate collision into two distinct categories, even though players often use the word "hitbox" loosely to mean both.

A hitbox is the shape that deals damage. It is attached to an active attack: a fist, a sword blade, a bullet, a projectile. A hurtbox is the shape that receives damage. It is attached to the character's body, and it is usually present at all times a character exists, not just when they are attacking.

A hit registers the instant a hitbox and a hurtbox overlap during a frame the engine checks for collision, regardless of what the visible character models appear to be doing on screen. If a hitbox and a hurtbox never touch, no amount of visual closeness matters. If they do touch, even briefly and even if the animation looks unconvincing, the hit counts.

This separation is why competitive fighting game communities scrutinize hurtbox size so closely. A character with a visually large sprite but a small, tightly fitted hurtbox can dodge attacks that appear to graze them on screen, something players describe as a character having "good hurtboxes." Capcom's Street Fighter series has published detailed frame-data breakdowns of exactly this kind for its games, including Street Fighter V and Street Fighter 6, precisely because the invisible collision shapes, not the character art, determine what actually happens in a match (Capcom's official Street Fighter V frame data column, "The Basics of Attack Composition").

Counter-Strike used simple box-shaped hitboxes for more than a decade before Valve replaced them with capsule-shaped hit volumes in a September 15, 2015 update to Counter-Strike: Global Offensive. The new capsules, defined by a line segment and a radius, hugged the player model's limbs and torso far more closely than the old boxes, which had extended noticeably beyond the visible body and produced hits players felt should have missed (per [Valve's official patch notes and community documentation on the Counter-Strike Wiki](https://counterstrike.fandom.com/wiki/Counter-Strike:_Global_Offensive_patches/September_15,_2015)).

Why hitboxes almost never match the character model exactly

It might seem like the obvious fix for "unfair" hits and misses would be to make hitboxes match the visible art perfectly. In practice, almost no competitive game does this, for two separate reasons.

The first is performance, already covered above. The second is fairness and predictability, which is arguably the more important reason once a game reaches a competitive audience. A sword blade that is genuinely one pixel wide, with a hitbox that traces its exact rendered shape frame by frame, would create an absurdly precise and effectively random hit window. Whether an attack connects would depend on sub-pixel animation timing that no human could consciously track or predict, which makes a game feel arbitrary rather than skill-based.

Instead, developers deliberately simplify, and frequently shrink, hurtboxes relative to the visible model. A character's hurtbox is commonly set noticeably smaller than their sprite or model outline, so that near-misses look and feel like near-misses rather than pixel-perfect coin flips. This is a conscious design decision made by animators, designers, and engineers working together, not a limitation anyone is quietly trying to eliminate. Even in an era of far more computing power than fighting games had in the 1990s, current top-tier games like Street Fighter 6 and Guilty Gear Strive still use simplified capsule and box hurtboxes rather than mesh-accurate ones, because the design goal, consistent and learnable combat, favors simplicity over precision.

Why do attacks sometimes look like they missed but still count as hits?

Because the visible animation and the invisible hitbox are separate systems that do not always align in time. A hitbox is usually active for only a narrow window of frames within an attack's full animation, and that window does not always line up with the frame where the attack visually looks closest to the target, so a hit can register slightly before or after the moment it "looks right" on screen.

Why do some characters seem to dodge attacks that clearly should have connected?

Because their hurtbox is smaller than, or shaped differently from, their visible sprite or model. A character can visually lean into an attack's path while their actual collision volume, which is what the game checks, stays outside it, producing a dodge that looks implausible but is mechanically correct.

Frame data: the timing layer that governs when a hitbox is even active

Hitboxes don't exist continuously. In fighting games, every attack is broken into three timed phases, collectively called frame data, and hitboxes are only turned on during one of the three.

Startup is the period after a player presses the attack button but before the hitbox activates, during which the character is committed to the move but cannot yet deal damage. Active frames are the window during which the hitbox exists and can register a hit, commonly lasting only two or three frames for a fast attack. Recovery is the period after the active frames end, during which the character returns to a neutral, ready state but still cannot act. This three-phase structure is documented across official Capcom materials and widely used fighting game reference resources for titles including Street Fighter V and Street Fighter 6 (Street Fighter Wiki, Frame Data).

At a typical fighting game frame rate of 60 frames per second, a single frame lasts roughly 16.7 milliseconds. An attack with only two active frames has a hit window of about 33 milliseconds, which is faster than most people can consciously perceive, let alone react to. This is why fighting game players talk about "frame traps" and "punishing on reaction": high-level play depends on memorized timing and pattern recognition rather than raw reflexes, because the actual windows are simply too short to process in real time.

Collision approach	What it is	Accuracy to visible model	Relative performance cost	Where it's commonly used
Axis-aligned bounding box (AABB)	A box that never rotates, always aligned to world axes	Low — loose fit, especially on rotated or diagonal characters	Very low	Simple platformers, early 2D games, broad-phase collision checks
Oriented bounding box (OBB)	A box that rotates with the character or weapon	Medium — fits better than AABB but still boxy	Low to moderate	Many 3D action games, vehicle collision
Capsule collision	A cylinder with rounded end caps	Medium-high — hugs limbs and torsos closely	Moderate	Modern shooters (e.g., post-2015 Counter-Strike: Global Offensive), third-person action games
Per-frame animated hitboxes	Hand-authored shapes that change every animation frame	High — tuned individually per move and per frame	High	Competitive fighting games (Street Fighter, Guilty Gear, Mortal Kombat)
Pixel/mesh-accurate collision	Exact intersection of the rendered mesh or sprite	Highest — matches the visible art exactly	Very high, rarely used at runtime	Almost never used live; occasionally for offline hit-verification tools

Why hitbox sizing is a balance decision, not just an engineering shortcut

Once a shape and a timing window are chosen, their exact size and position become a lever designers pull deliberately, the same way they'd adjust a character's damage number or movement speed. A character whose attacks carry a large hitbox while their own hurtbox stays small has a structural advantage: they can land hits from further away or through more generous timing while being comparatively hard to hit in return.

This is why patch notes for competitive games routinely call out hitbox and hurtbox changes as balance changes in their own right, separate from any change to visible character art or damage values. Blizzard's Overwatch is a well-documented example: Roadhog's hook ability, which pulls an enemy toward him if it connects, went through a widely discussed rework known informally as "Hook 2.0," in which the line-of-sight check for whether the hook could connect was moved to be measured from Roadhog's own position rather than from the hook itself, specifically so the hook could no longer connect with targets Roadhog could not actually see (community and forum documentation of Blizzard's Roadhog hook changes). Roadhog's hook and its associated hitbox behavior were the subject of further balance passes in subsequent seasons, underlining that this kind of collision tuning is an ongoing, active part of competitive game maintenance rather than a one-time fix.

Networked multiplayer games add a further wrinkle: server-side hit registration often needs lag compensation, a technique in which the server briefly rewinds hitbox positions to where an opposing player's client believed they were at the moment that player fired, rather than where they had actually moved to on the server's own timeline by the time the shot's data arrived. This is a deliberate tradeoff to keep shooting feel responsive despite network latency, and it introduces its own set of fairness debates that are large enough to be their own topic. For a deeper look at exactly how and why that specific tradeoff generates controversy, see why lag compensation is controversial.

Common misconceptions about hitboxes

"A hit should register whenever the visible models touch." This is the single most common source of frustration, and it is a misunderstanding of what the game is actually checking. The engine only evaluates the underlying simplified hitbox and hurtbox shapes, which are frequently smaller, larger, or positioned differently than the visible character art. A "that should have hit" moment usually reflects a genuine, measurable gap between the visual layer and the collision layer, not a bug or lag, though lag can make the gap worse.

"Every attack on a character uses the same hitbox shape." In fighting games especially, this is false. Developers typically define a distinct hitbox shape, size, and active-frame window for each individual attack a character has, tuned separately as part of that character's overall balance profile. A character's light punch and heavy kick will usually have entirely different hitboxes, not a scaled version of the same one.

"Simplified hitboxes are a limitation developers would remove given enough computing power." Modern hardware could technically support far more detailed collision checking than most competitive games actually use. Developers still choose simplified shapes because consistency and predictability, not maximum geometric fidelity, are the actual design goal. A pixel-accurate hit window would make outcomes harder to learn and predict, which most competitive communities would consider a worse game, not a better one.

"Hurtboxes and hitboxes are the same thing." They frequently get conflated in casual conversation, but they serve opposite functions: one deals damage, the other receives it, and a single character can have both active simultaneously, for instance a hurtbox on their body while a hitbox exists on the weapon they are currently swinging.

How hitbox design connects to the rest of a game's technical foundation

Hitbox and hurtbox systems don't exist in isolation. They interact with a game's physics tick rate, its animation system, and, in multiplayer titles, its network model. A game that runs its simulation at a lower internal tick rate than its visible frame rate can end up checking hitboxes less often than the screen updates, which is a separate and additional source of the "should have hit" gap beyond simple hitbox-versus-model mismatch. This is one reason competitive shooters are often built and marketed around specific, stable tick rates rather than just a target frame rate, since the tick rate governs how often hit detection itself actually runs, independent of how smooth the game looks.

Animation and hitbox timing are also tightly linked. A character's hitbox activation is authored to align with a specific point in their attack animation, but if that animation is later adjusted, sped up, or given new visual effects without an equivalent adjustment to the hitbox's active-frame window, the visual and collision layers can drift out of sync. This is part of why animation changes in a balance patch sometimes come with separate hitbox timing notes, even when the underlying frame data numbers look unchanged on paper. For readers interested in how the broader visual pipeline that surrounds these collision systems gets built, how game engines render lighting covers a related but distinct part of that same rendering and simulation stack, and why frame rate changes game feel covers how the frame-timing side of this relationship affects what a hit or dodge actually feels like to a player in the moment.

The takeaway

Hitboxes work by replacing complex character geometry with simplified shapes, boxes, capsules, or spheres, that are cheap to test for overlap on every frame, which is why whether an attack lands depends on invisible collision geometry rather than the visible character art. Hurtboxes and hitboxes are deliberately distinct systems, sized and timed separately as an active balance tool that shows up explicitly in patch notes for games like Street Fighter and Overwatch, not as a passive technical limitation. Once you understand that the collision layer and the visual layer are two separate systems that only sometimes line up perfectly, most "that should have hit" or "that should have missed" moments in any hitbox-based game stop feeling like bugs and start feeling like the predictable result of a deliberate design tradeoff.

---

Read next:

• Why lag compensation is controversial
• How game engines render lighting
• Why frame rate changes game feel

FAQ

Q: What is the difference between a hitbox and a hurtbox?

A hitbox is the collision shape that deals damage, typically attached to an attack, weapon, or projectile. A hurtbox is the collision shape that receives damage, typically attached to a character's body and present whenever the character exists, not only during an attack. A hit registers the instant a hitbox overlaps a hurtbox, regardless of what the visible models appear to be doing.

Q: Why don't hitboxes match the visible character model exactly?

Matching a hitbox precisely to detailed character art would be computationally expensive to check every frame, and it would also make combat feel arbitrary, since a razor-thin visual detail like a blade edge would create an unreasonably precise and unpredictable hit window. Developers use simplified, often smaller shapes so combat feels consistent and learnable rather than pixel-perfect and erratic.

Q: Why do some attacks look like they missed even though they visually connected?

Because a hitbox is only active during a specific, often very short window of animation frames, sometimes as few as two or three frames at 60 frames per second. If the point where the attack visually looks closest to the target does not fall inside that active window, the attack can appear to connect while the underlying hitbox and hurtbox never actually overlapped.

Q: Do all characters in a fighting game use the same size hitboxes?

No. Hitbox and hurtbox sizes and shapes are typically tuned individually per character and often per move, as a deliberate balance decision that affects how easily a character can land hits versus how easily they can be hit in return. Official frame-data references for games like Street Fighter document these differences move by move.

Q: What is frame data and how does it relate to hitboxes?

Frame data describes the timing of an attack in three phases: startup (before the hitbox activates), active frames (when the hitbox can register a hit), and recovery (after the hitbox deactivates, before the character can act again). Frame data determines exactly when a hitbox turns on and off, not just what shape it has.

Q: Can hitbox size or shape change after a game is released?

Yes. Developers frequently adjust hitbox and hurtbox sizes, shapes, or timing in post-launch balance patches, and these changes are commonly listed explicitly in patch notes as gameplay or balance changes, separate from any visual or animation update. Overwatch's revisions to Roadhog's hook collision behavior are one documented example of this kind of adjustment.