box-sizing in CSS: why your width never comes out the size you set

You set width: 300px on a card, add some padding to give it room, and the card suddenly renders at 340 pixels on screen. That is not a bug: it is the default behaviour of the Box model in every browser. box-sizing is the property that changes it, once and for all, right at the top of a stylesheet.

Understanding this property saves hours of unnecessary mental arithmetic, and explains why almost no professional project settles for the browser's default setting.

Definition

box-sizing decides what width and height actually measure: content only, or content plus padding and border added together. Two values stand against each other, content-box, the default behaviour, and border-box, the one nearly every site adopts on purpose.

.card {
  box-sizing: border-box;
  width: 300px;
  padding: 20px;
  border: 2px solid #1f2937;
}

/* Final width on screen: exactly 300px */

content-box: the default behaviour

With no box-sizing declared, a browser applies content-box: width only sets the content's width, padding and border are added on top, growing the box beyond the value written.

With content-box, adding padding without ever touching width makes every box grow, an effect that cascades across a whole grid of cards meant to share the same width.

border-box: everything included in the width

With box-sizing: border-box, width becomes the final size actually rendered, the one you see and measure. Padding and border eat into the space left for the content, never grow the box beyond the declared value.

This is what makes layout math predictable: a three-column grid at 33% each stays at 33%, even after adding padding or a border to every column.

The universal reset: box-sizing: border-box everywhere

*,
*::before,
*::after {
  box-sizing: border-box;
}

This rule, applied to the universal selector, sits at the top of almost every professional stylesheet, often as part of a broader CSS reset and normalize. It applies border-box to every element on the page, including ones generated by ::before and ::after, with no case-by-case exceptions to manage. Our HTML and CSS course has learners set this reset on their very first stylesheet, so it becomes a reflex before they ever run into the problem it solves.

A common case: form fields

Form elements, input, textarea and button, long inherited their own box-sizing tied to the operating system rather than the stylesheet, causing inconsistent border overflow across browsers. The reset's universal selector covers them today with no exceptions, but checking this remains a good habit on an older project that never explicitly set this reset.

Frequently asked questions

No, the value written in the code stays identical. What changes is what it actually measures on screen: content only under content-box, or the whole box, padding and border included, under border-box.

In practice, yes: it has become a de facto standard because it simplifies layout math so much. The only caution applies to an already advanced project, where changing it midway can slightly shift sizes already tuned to the old behaviour.

No, these are two completely independent mechanisms. box-sizing never touches margin, which stays outside the box no matter which value is chosen, and therefore keeps collapsing vertically under the exact same conditions.