Skip to content
Juno Park

Designer and developer

All writing

The four-pixel rule

February 11, 2026

5 min read

I have a bad habit of measuring other people's websites. Not the layout — the movement. How far does a row shift when you hover it? How far does a button sink when you press it? I have been writing the numbers down for about a year, and the answer is almost always four pixels.

Four is small enough that you do not consciously register it as animation. It reads as response. Six starts to feel like a gesture. Eight is a decision the interface made without asking you. And two might as well be zero — on a laptop trackpad, moving a title two pixels is indistinguishable from the cursor jitter that caused it.

The distance is doing a specific job

Hover feedback answers one question: is this thing I am pointing at the thing I think I am pointing at? That is the whole job. It is a confirmation, not a performance. Once you frame it that way, the size of the movement stops being a taste question and starts being a legibility question — how little can it move and still be unmistakably intentional?

Four pixels, in my measuring, is the floor. Below it you need a second channel — a color change, an underline, a cursor swap — to carry the signal, because the movement alone will not survive a cheap monitor or a moving hand.

Hover feedback is a confirmation, not a performance.

What breaks when you go bigger

The failure mode of a large hover is not ugliness. It is that the page becomes unstable. If a list row grows on hover, every row below it moves. Now the thing you were about to click has relocated. I have watched people miss a link three times in a row because the list kept rearranging itself underneath them, and each time they blamed themselves.

This is why I have mostly stopped animating anything that affects layout. Translate, do not grow. Fade, do not expand. If the row must change height, change it on click, when the user has already committed.

A short list of things that should not move on hover

  • Anything that would reflow its siblings
  • Anything inside a scrolling container the user is actively scrolling
  • Anything the user has to hit twice in a row
  • Anything on a touch device, where hover does not exist and the state gets stuck

Where the budget should actually go

If four pixels is enough for the movement, the interesting question becomes what else the hover can say. My favourite answer is: reveal the next step. A list of articles where hovering swaps the date for the word Read tells you something the date never did — that this row is a door.

That swap costs nothing if you put both labels in the same grid cell and cross-fade the opacity. No layout, no reflow, no measurement. The row stays exactly where it was, and it has told you what it does.

I spent three weeks on the hover state of a single list last spring. I am not proud of the arithmetic on that, but I use that list every day and it still feels correct, which is more than I can say for most of what I shipped that year.