The CSS Box Model: Understanding Width, Spacing, and Overflow

A card is supposed to fit inside a 300-pixel column. Its CSS sets width: 300px, but adding padding pushes the right edge beyond the column. A developer reduces the width until it looks correct, then discovers that another card needs a different adjustment. The immediate symptom is spacing; the underlying issue is which part of the box the width describes.

The CSS box model separates content, padding, border, and margin. Understanding those areas lets you explain a rendered size instead of compensating for it through repeated visual adjustments. Layout rules still determine how boxes interact, but the box model provides the dimensions those rules work with.

Begin with a normal block box in a horizontal writing mode. Once that case is clear, it becomes easier to identify where inline layout, flexbox, grid, or intrinsic sizing adds another condition.

Identify the four areas

The content box holds the content. Padding surrounds that content inside the border, while margin sits outside the border. The CSS Box Model specification defines these areas and their edges.

A card background normally extends through its padding, subject to background painting settings. Margin is outside the card’s border and does not create more interior background. This distinction is useful when a design calls for more space around text versus more separation between neighbouring components.

The areas around a content box

The diagram describes a box, not an unconditional rule that every HTML element produces exactly one rectangle. The CSS Display specification explains box generation. An element with display: none produces no boxes, while inline content may be fragmented across lines. Inspect the actual formatting context before applying a block-box calculation to everything on the page.

Calculate the border box before including margin

Consider a card with explicit sizing so the example does not depend on a site’s reset styles:

.card {
  box-sizing: content-box;
  width: 300px;
  padding: 20px;
  border: 2px solid;
  margin-inline: 10px;
}

Under content-box, the declared width applies to the content. Each side adds 20 pixels of padding and 2 pixels of border, producing a 344-pixel border box. The two 10-pixel horizontal margins lie outside it. In this simple case, they bring the margin-box width to 364 pixels.

Changing only box-sizing changes the interpretation of the declared width:

The margins remain outside both calculations. The table assumes the stated width is used without another layout constraint changing it. Minimum and maximum sizes, flex sizing, and available space can add further conditions in a real layout.

CSS Sizing defines box-sizing, including the rule that the content size cannot become negative. If padding and borders alone exceed a declared border-box size, the outer box cannot simply shrink them into a negative content area. Border-box is a sizing rule, not a guarantee that every combination of dimensions fits.

Use a consistent sizing convention deliberately

Many sites choose border-box so component widths include padding and borders. A common reset applies it through inheritance, including pseudo-elements:

html {
  box-sizing: border-box;
}

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

This makes it easier to set a card’s width without separately subtracting interior spacing. It also makes a local override possible by changing a component’s sizing convention and allowing descendants to inherit it. Review third-party components if their styles expect a different convention.

Do not assume the effective sizing mode from the element’s tag. Browser styles and application styles can set different values. Mozilla’s box-sizing reference documents the property and relevant defaults. The computed value in the browser is the useful evidence for the element being debugged.

A responsive card often benefits from a maximum width and a flexible available width rather than a rigid width everywhere. Border-box helps account for interior spacing, but it does not decide which width is appropriate for a narrow screen. That remains a layout choice informed by the content and its container.

For example, setting a border-box child to width: 100% accounts for its own padding and border, but adding horizontal margins still places those margins outside that width. It can therefore exceed the containing space despite using border-box. Moving sibling separation into a parent gap, or choosing a sizing arrangement that accounts for the margins, addresses the relationship causing the problem.

Also distinguish an explicit percentage width from automatic block sizing. A normal block with automatic width can distribute available horizontal space according to its layout rules; it is not equivalent to setting every block to 100%. Before introducing a percentage to fix one component, check whether the existing automatic sizing already expresses the intended fit.

Choose spacing by the relationship it expresses

Use padding when the space belongs inside a component, such as the distance between a card’s text and its border. Use margin when the spacing belongs outside that box. For repeated children in a flex or grid layout, gap can express separation at the container level.

For example, a results list can give each card its own interior padding while the parent controls the gap between cards. That keeps the spacing between results consistent without requiring every card to know whether it is first or last. It also separates the component’s interior design from the page’s arrangement of components.

Be careful when combining gap and margins: both can contribute space. If a layout looks unexpectedly loose, inspect the parent as well as the children before reducing the card’s padding. Otherwise a correction to external separation can accidentally make the card’s content too cramped.

Logical properties such as padding-inline and margin-block can express spacing in relation to writing direction. They are useful when the design should follow text flow. Keep that convention consistent so a mixture of physical and logical declarations does not obscure which side is being controlled.

Understand when margins collapse

In ordinary block layout, adjoining vertical margins can collapse. With two qualifying positive margins of 30 pixels and 20 pixels, the collapsed result is 30 pixels, rather than their sum. This is why increasing one paragraph’s margin may appear to have no effect until it exceeds its neighbour’s margin.

The CSS margin collapsing rules also cover parent-and-child relationships and negative margins. The larger-margin shortcut describes the positive example, not every case. Borders, padding, formatting contexts, and layout mode affect whether margins can adjoin and collapse.

Do not generalise this behaviour to every pair of spaces. Horizontal margins do not collapse, padding does not collapse, and margins between flex or grid items do not collapse as ordinary block margins do. If an intended interior offset disappears, check whether the chosen margin is participating in collapse with a parent.

Use the spacing mechanism that matches the design instead of adding an unrelated border merely to change the symptom. Parent padding may express an intended interior inset directly. A flex or grid arrangement with gap may express consistent sibling separation more clearly than a collection of interacting block margins.

Overflow can come from content and layout constraints

A correctly calculated border box can still contain overflowing content. A long unbroken identifier, a large image, or a child with an explicit minimum size may require more space than the available area. Changing box-sizing does not remove those constraints.

Flex items have automatic minimum sizing behaviour that can prevent the shrinking a developer expects. The Flexbox specification describes that rule. Where appropriate, allowing a content region to shrink with min-width: 0 can be part of the repair, together with a deliberate policy for wrapping or scrolling its contents.

For an article table, horizontal scrolling can preserve the relationship between columns when narrow-screen wrapping would make the cells unreadable. For a prose paragraph, wrapping is usually more useful. For an image, responsive sizing may preserve the content without overflow. Choose the behaviour according to what readers need to see and compare.

Avoid treating overflow: hidden as a general fit adjustment. It can conceal material that is still too large, including controls or text readers need. Fixed heights deserve similar scrutiny when content can grow through localisation, user settings, validation messages, or ordinary editing.

Debug from the computed box outward

Select the element in browser developer tools and inspect its computed dimensions, padding, borders, margins, and box-sizing. Chrome’s CSS tools reference describes inspection and editing features. Then inspect the parent layout, including available width, gap, and alignment.

Change one relevant condition at a time. If the border box is too wide, explain its width calculation first. If the box fits but text escapes, inspect content wrapping and minimum sizes. If the gap is surprising, identify which margins or container rules contribute it. This produces a repair tied to the cause rather than another compensating offset.

Finally, check the affected component at narrow and wide widths with realistic content. Playwright-based browser checks can help preserve important layout behaviour, while vector and raster image choices explain a separate part of sizing visual content. Keep the calculation, the layout context, and the content requirements visible together when reviewing the result.