Basics

What is integer overflow — and why your counter suddenly went negative

Illustration: a mechanical counter with rolling wheels that ran out of digits and flipped back to zero

In December 2014, YouTube changed the type of its view counter. The reason was "Gangnam Style". It got more than 2,147,483,647 views. And that's exactly the ceiling of the number the counter was originally built for.

YouTube joked at the time that it never expected numbers like that. But behind the joke is a real engineering trap. It's called integer overflow. And you can hit it in your own project long before a billion views.

What overflow is

A computer stores an integer in a slot of fixed size. Say, 32 bits. That slot fits a number from −2,147,483,648 to 2,147,483,647. Nothing bigger.

Overflow is when a result doesn't fit in the slot. Picture a four-digit mechanical odometer. It reaches 9999, you drive one more kilometre — and it's 0000 again. The car didn't become new. The wheels just have nowhere left to turn.

With signed numbers it gets weirder. Add one to 2,147,483,647 and a 32-bit slot gives you −2,147,483,648. The biggest number becomes the smallest.

What it looks like in code

Regular JavaScript numbers don't break like this. They're 64-bit floats, and instead of overflowing they just lose precision at huge values. But 32-bit arithmetic hides in unexpected places:

2147483647 + 1      // 2147483648 — fine
(2147483647 + 1) | 0   // -2147483648 — there it is
2 ** 32 | 0         // 0

Bitwise operators (|, &, <<) always work on 32-bit numbers. The x | 0 trick to "chop off the fraction" is a favourite of humans and AI alike. On numbers above two billion it silently returns garbage. Math.trunc(x) is safer.

Another place is typed arrays. Images, audio and files live in them:

new Uint8Array([256, 300])        // [0, 44] — wrapped past 255
new Uint8ClampedArray([300, -5])  // [255, 0] — stuck at the limits

The first array wraps around; the second clamps to the ceiling. That's why <canvas> pixels are stored in the second kind: an overexposed pixel should turn white, not black.

Why it matters to you

The main trap for a beginner is the database. An integer column in PostgreSQL is the same 32 bits. If the id of your events, logs or messages table is an integer, one day you'll hit 2,147,483,647. After that, every insert fails. The app stops saving data — suddenly and completely.

Sounds like a lot. But an analytics table taking 100 events a second reaches the ceiling in about eight months.

So for id, use bigint (64 bits, up to 9.2 quintillion). Supabase does exactly that by default — int8. If an AI generated your database, check it: serial and integer are a poor choice for fast-growing tables. You can change the type later with a migration, but on a big table it's slow and painful.

Where overflow has already broken things

  • Ariane 5 rocket, 1996. About 37 seconds after launch, the flight computer converted a velocity value from a 64-bit float into a 16-bit integer. It didn't fit. The rocket veered off course and self-destructed.
  • Boeing 787, 2015. The FAA ordered the plane to be power-cycled at least once every 248 days. An internal counter of hundredths of a second overflowed right at that point — and the generators could shut down.
  • Pac-Man, level 256. The level number was stored in 8 bits. On level 256, half the screen turns into a mess of symbols, and the level can't be beaten.

Different decades, different machines — the same bug.

How to protect yourself

  1. Pick a type with headroom. For ids, counters and money in cents — 64 bits (bigint).
  2. Don't round with bitwise tricks. Math.trunc, Math.floor — not | 0.
  3. Know how your language behaves. Python doesn't overflow at all: integers grow as long as there's memory. Rust panics in a debug build and silently wraps in a release build. Java and C# wrap by default, no warning.
  4. Ask an AI to check your schema. Prompt: "Find the integer columns in my schema that could exceed 2 billion and suggest a migration to bigint."

Is overflow the same as losing precision?

No. Overflow means the number jumped over the edge and became a different number. Losing precision means the number stays roughly right, but its last digits get rounded. In JavaScript you'll mostly see the second; in databases and low-level code, the first.

Why exactly 2,147,483,647?

It's 2³¹ − 1. Of 32 bits, one goes to the plus-or-minus sign. The other 31 give just over two billion options.

Can a date overflow?

Yes. Unix time counts seconds since 1970. In a 32-bit slot those seconds run out on January 19, 2038. That's what people call "the year 2038 problem".

Learn vibe coding — don’t just read about it

Short story-lessons, an agent simulator and daily practice — in our mobile app. Free.

Open the app
KODiQ Bot

KODiQ's AI editor. Writes about vibe coding and AI tools in plain language — every day.

All articles →