CSS Box Model Explained: Content, Padding, Border, Margin and box-sizing

The CSS box model describes every element on a page as four nested rectangles: the content box, wrapped by padding, wrapped by the border, wrapped by the margin. In the standard box model the width and height you write apply only to the content box, so padding and border are added on top of that number — which is exactly why a box you sized at 300px often measures wider than 300px on screen.

The four areas, from the inside out

• Content box — where your text, images, or child elements live. In the standard box model this is what width and height size.
• Padding box — breathing room inside the border, set with padding. The element's background paints through it, and padding can never be negative: negative values are invalid and the whole declaration is dropped.
• Border box — the visible edge drawn by border. This is the rectangle a user perceives as "the box."
• Margin box — transparent space outside the border that pushes neighbours away. Margin is never part of the element's own size in either box-sizing mode, and unlike padding it may be negative.

One useful outlier: outline is drawn outside the border but takes up no space at all, so it never shifts the layout. That is why focus rings are outlines rather than borders.

Two ways to measure: content-box vs border-box

The box-sizing property decides what your width number is measuring. It has two values you will use — content-box and border-box — and the initial value is content-box.

.card {
  width: 300px;
  padding: 20px;
  border: 2px solid #333;
}
/* content-box (initial): rendered box = 300 + 20+20 + 2+2 = 344px */

.card { box-sizing: border-box; }
/* border-box: rendered box = 300px; content shrinks to 256px */

With border-box, the declared width covers content + padding + border, and the content area absorbs the difference. If padding and border together exceed the declared width, the content box floors at 0 rather than going negative — you cannot shrink an element away with border-box. Because box-sizing is not inherited, most developers apply it globally with a *, *::before, *::after rule. Note that browser default stylesheets already use border-box for a handful of elements, including <table>, <select>, <button>, and several <input> types, so "the browser default" is not universally content-box.

Why block-direction margins collapse

Margin collapsing is the rule that surprises people. When the bottom margin of one in-flow block box touches the top margin of the next, the two do not add up — they collapse into a single margin equal to the larger of the two. A 40px bottom margin meeting a 24px top margin yields 40px of space, not 64px. Two margins count as adjoining only when both belong to in-flow block-level boxes in the same block formatting context and no line box, clearance, padding, or border separates them.

Collapsing also happens between a parent and its first in-flow child (top margins) when the parent has no top border, no top padding, and no inline content, and between a parent and its last in-flow child (bottom margins) when the parent additionally has no fixed height or min-height. An empty block with nothing to separate its own top and bottom margins collapses them together too. Collapsing occurs only in the block direction — vertically, in a standard horizontal writing mode. Horizontal margins never collapse.

When margins do not collapse

• Floated boxes: margins between a float and any other box do not collapse.
• Absolutely positioned boxes.
• Flex items and grid items — margins never collapse inside a display: flex or display: grid container.
• A box that establishes a new block formatting context (for example display: flow-root or overflow: hidden) does not collapse its margins with its own in-flow children.
• Inline-level and inline-block boxes.

Ready to practice? Work the questions below, then keep going with the WGU D276 Web Development Foundations study guide or more D276 practice questions.

A worked example: the three-column row that overflows

Here is the bug that teaches this concept faster than any diagram. You want three equal cards across a 900px container:

.card {
  width: 33.3333%;
  padding: 16px;
  border: 1px solid #ccc;
  float: left;
}

Each card's content box is about 300px, but the rendered border box is 300 + 32 + 2 = 334px. Three of those is 1002px, which does not fit in 900px, so the third card drops to a new line. The fix is one declaration, not a recalculation of the percentages:

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

Now 33.3333% is the rendered width, padding and border eat into the content area, and the row fits. This is why so many modern stylesheets and CSS frameworks open with that reset — and why box-sizing needs the universal selector plus the pseudo-element selectors: the property is not inherited, and * does not match ::before or ::after on its own.

Mistakes people actually make

• Counting margin as part of the width. Neither box-sizing mode includes margin. If you need the total footprint an element claims in a row, you add margins yourself, on top of the border box.
• Expecting adjoining vertical margins to add. Two 20px margins between stacked in-flow blocks give you 20px, not 40px. Teams sidestep the whole question by setting margins in one direction only — for example margin-bottom (or its logical equivalent margin-block-end) on every block and zero on top.
• Using outline and border interchangeably. A border changes layout; an outline occupies no space, which is why it is the safe choice for focus rings and for debugging without shifting anything.
• Assuming vertical percentage padding follows height. It follows the containing block's width.
• Trying to use negative padding. Negative padding values are invalid; only margins can be negative.

How to reason about the tricky cases

When spacing looks wrong, ask two questions in order. First: what is my width actually measuring? Open DevTools, look at the computed box diagram, and compare the content number to the number you typed. If they differ, you are in content-box.

Second: is a margin escaping? If a gap appears outside a container rather than inside it, a child's margin has collapsed through the parent. Anything that separates the two edges stops it — top padding, a top border, or inline content. So does making the parent establish a new block formatting context with display: flow-root or overflow: hidden, since such a box does not collapse margins with its in-flow children. Turning the parent into a flex or grid container also stops it, because margins never collapse inside a flex or grid container. That is one quiet reason modern layouts feel more predictable than float-based ones.

For negative margins, the rule is arithmetic rather than magic: the collapsed margin is the largest positive margin plus the most negative one. A 30px bottom margin adjoining a −10px top margin leaves 20px of space. When every adjoining margin is negative, the result is simply the most negative of them.

References: MDN: Introduction to the CSS box model and W3C CSS 2.2, section 8.3.1: Collapsing margins.