How Chrome Dino’s Collision Detection Works (Code Look)

Anyone who has played the Chrome Dino game long enough has had the moment: you jump, you swear you cleared the cactus, and the game ends anyway. Chrome Dino collision detection is doing exactly what it’s coded to do — there’s no luck involved, no hidden randomness. The hitboxes are rectangles, the test is simple math, and the source is open. Here’s what actually happens between two frames.

The game loop, in one sentence

Every frame, the game updates the dino’s position, scrolls obstacles toward it, and asks one question: do any of the dino’s bounding boxes overlap any of the next obstacle’s bounding boxes? If yes, game over. If no, render and repeat.

This loop runs at roughly 60 frames per second on modern hardware. That means the collision test fires sixty times a second, and a hit detected in any one frame ends the run. The dino doesn’t have momentum carried into the next frame for collision purposes — only its current position matters.

What AABB collision means

AABB stands for axis-aligned bounding box. The “axis-aligned” part is important: every hitbox is a rectangle whose sides line up with the screen’s X and Y axes. No rotation, no diagonals. The test for whether two AABBs overlap is four comparisons:

• Box A’s right edge is past Box B’s left edge.
• Box A’s left edge is before Box B’s right edge.
• Box A’s bottom edge is past Box B’s top edge.
• Box A’s top edge is before Box B’s bottom edge.

If all four conditions are true, the boxes overlap. The check is cheap — a handful of subtractions and comparisons per pair. That’s why arcade-style games love AABB: you can run it many times per frame without breaking the frame budget.

The dino’s hitboxes

The T-Rex sprite isn’t a single rectangle. If it were, the head and tail would generate false hits because they extend past the body’s effective collision area. Instead the dino carries a small array of sub-boxes that approximate its outline. The wayou fork’s source defines these as a list of x, y, width, height tuples relative to the sprite’s anchor.

When the dino is running, the boxes cover its body and head. When it ducks, the box set switches — the head box shifts forward and downward, and the body box flattens. This is why ducking under a pterodactyl actually works: the hitbox profile changes shape with the animation.

Obstacle hitboxes

Cacti have their own per-sprite hitbox arrays. A single small cactus is a couple of boxes — a vertical trunk and an arm or two. A wide cactus cluster is more boxes laid horizontally. The pterodactyl has wing-up and wing-down hitbox configurations that cycle with its flap animation.

The key thing to note: the hitboxes don’t perfectly match the rendered sprite. They approximate it. A pixel of cactus that extends past a hitbox edge is harmless. A pixel of empty space inside a hitbox is still a collision. That mismatch is the source of most “I cleared it!” arguments.

The collision routine, step by step

Per frame, the loop does roughly the following for the next obstacle on screen:

1. Compute a coarse AABB for the dino as a whole (the outer bounding rectangle).
2. Compute a coarse AABB for the obstacle as a whole.
3. If the coarse boxes don’t overlap, return false immediately. (This is the fast-out.)
4. If the coarse boxes do overlap, iterate over every dino sub-box paired with every obstacle sub-box.
5. Run the four-comparison AABB test on each pair.
6. The first overlapping pair returns true — that’s a hit.

The two-tier check (coarse box first, sub-boxes only if the coarse boxes intersect) is a standard optimization. Most frames the dino is nowhere near the obstacle, so the coarse-box test returns false in nanoseconds and the loop moves on.

Why close calls feel unfair

Three reasons. First, the sprite has anti-aliased pixels at its edges that visually suggest a larger silhouette than the hitbox represents. The eye sees the soft edge and reads it as the boundary, but the collision math doesn’t.

Second, animation frames don’t always match hitbox switches one-to-one. There can be a single frame where the visible sprite has updated but the hitbox set hasn’t yet, or vice versa. At 60 FPS, that frame is 16 milliseconds — not long enough to perceive, long enough to lose a run.

Third, the game’s scroll speed accelerates over time. As speed climbs, the distance the obstacle travels between two frames increases. By the time the game is fast enough to be hard, an obstacle can cross 20 to 30 pixels in a single frame. If your jump apex falls just before that pixel range, you clear it. If it falls inside the range, you don’t.

Reading the source yourself

The version most browser ports of Chrome Dino derive from is the BSD-3-licensed fork at github.com/wayou/t-rex-runner. The collision routine lives in the main game file, in a function typically named checkForCollision. The hitbox arrays are defined as static properties on the obstacle and dino classes — easy to find by searching for “collisionBoxes” or “CollisionBox.”

If you want a walkthrough of the rest of the engine, our piece on the Chrome Dino source code covers the broader structure — the game loop, the sprite atlas, the day-night cycle, and the offline trigger logic.

Why not pixel-perfect collision?

Pixel-perfect collision tests every overlapping pixel between two sprites and checks if both are non-transparent. It’s more accurate but much more expensive — orders of magnitude more comparisons per check. For a 60 FPS game running in a browser tab, the cost wasn’t worth the small accuracy gain. AABB is good enough, and it makes the game’s behavior deterministic in a way pixel-perfect testing wouldn’t easily allow.

The trade-off is the close-call problem. Players occasionally feel cheated. The alternative — pixel-perfect — would feel fairer in those moments but would tax low-end devices and make the game’s hitbox tuning a per-frame art problem. The engineering choice was the right one for a Chrome easter egg.

Custom forks and modified hitboxes

Because the source is open, several modified versions of the T-Rex Runner exist with tweaked hitboxes. Some make the boxes smaller to favor the player; some make them larger as a hard mode. None of these are the original game — the canonical hitbox set is the one in Google’s released sprite atlas and the wayou fork that mirrors it.

What you can do about close calls

Not much. The hitboxes are what they are. But two things help in practice. Jump slightly earlier than feels right, especially as the game speeds up. The dino’s leading edge is the head, and clearing that means timing the jump to where the head’s box is past the obstacle’s box, not where the body looks like it’s clear.

And when a pterodactyl flies low, duck. Don’t jump. The duck hitbox profile is narrower and lower, and ptero collisions are decided by the head’s top edge — exactly where ducking helps.

Frequently asked questions

What kind of collision detection does Chrome Dino use?

Chrome Dino uses axis-aligned bounding box (AABB) collision detection. Each sprite is approximated by one or more rectangles, and the game checks per frame whether any rectangle from the dino overlaps any rectangle from the nearest obstacle.

Why do I sometimes lose when I clearly jumped over the cactus?

The hitboxes don’t match the rendered sprite exactly. A few pixels of cactus that look clear of the dino’s foot may still be inside a bounding box. Sprite anti-aliasing also makes obstacles look bigger than their collision rectangles actually are.

Is Chrome Dino’s source code public?

Yes. The widely used fork by wayou is BSD-3-licensed and hosted on GitHub at github.com/wayou/t-rex-runner. The collision routine and hitbox arrays are in the main game file and are straightforward to read.

How often does the collision check run?

Once per rendered frame, which is roughly 60 times per second in a modern browser. A collision detected on any frame ends the run immediately.

Does the dino’s hitbox change when it ducks?

Yes. Ducking switches the dino to a different hitbox configuration — a flatter, more forward-extended box set that lets it pass under pterodactyls. The jumping hitbox is the same as the running one; only ducking changes the shape.

The takeaway

Chrome Dino’s collision detection is a textbook AABB implementation: fast, deterministic, and slightly imperfect at the sprite edges. The math is open, the source is online, and the close-call frustrations are an engineering trade-off, not a bug. Next time the cactus catches you mid-air, you’ll know exactly which rectangle to blame.