CSS Box Model Inspector — Free HTML CSS JS Snippet

The CSS box model is one of those things every developer technically knows and regularly gets wrong anyway, usually because the effect of a padding or border change on the element's final rendered size is invisible until you actually measure it in DevTools. This snippet turns the box model into something you manipulate directly: four nested, color-coded layers — content, padding, border, margin — each with independent per-side sliders, animated transitions between values, and a live toggle between box-sizing: content-box and border-box so the single most common source of layout bugs becomes something you can watch happen instead of something you have to remember.

Structure: nested divs mirror the spec's own model

The DOM is four literally nested <div> elements — .margin-layer wraps .border-layer wraps .padding-layer wraps .content-box — which mirrors how the CSS spec itself describes the box model as a set of concentric edges (margin edge, border edge, padding edge, content edge) around a single element. Rather than drawing four separate rectangles with manual math, each "layer" is simply the previous layer's padding: the orange margin layer uses its own CSS padding property to create visible space before the yellow border layer begins, the yellow layer uses border-width to create the border band, and the green padding layer uses padding again before the indigo content box. This means the browser's own layout engine is doing all the geometry — the script only ever sets style.padding and style.borderWidth in pixels per side, and CSS lays out the rest.

The color convention is deliberately borrowed from DevTools

Content renders indigo/blue, padding green, border gold/yellow, margin orange — the same four-color convention Chrome, Firefox, and Safari all use in their built-in box-model inspector overlays. This is not arbitrary; matching the browser's own convention means the mental model you build here transfers directly the next time you open DevTools and hover an element, instead of teaching you a second color scheme to translate from.

Per-side sliders and the "link sides" toggle

Each of the three groups (padding, border, margin) renders four range inputs, one per side (top, right, bottom, left), built programmatically in buildSliders() rather than hand-written four times over — a single groups array drives the DOM generation, so extending the max range or adding a fourth group needs one array edit, not four copy-pasted blocks. A "link sides" checkbox controls whether dragging one slider updates all four sides of that layer at once (the common case, uniform spacing) or just the one side you touched (for exploring asymmetric layouts, like a card with extra top padding). The linked/unlinked logic lives entirely in onSlide(), which either broadcasts the new value to all four SIDES or writes to a single one, then calls render().

Why the layers visibly animate instead of snapping

Every layer's CSS declares transition: padding 0.28s, border-width 0.28s, width 0.28s, height 0.28s with a cubic-bezier(0.4,0,0.2,1) ease — the same "standard" easing curve Material Design uses for size changes. Because padding and border-width are both natively animatable CSS properties, dragging a slider doesn't need a JavaScript animation loop at all: the script just writes the new pixel value to style.padding on every input event, and the browser's compositor interpolates the visual change smoothly between the old and new value. This is a deliberate choice over animating with requestAnimationFrame — CSS transitions here are simpler, smoother, and free of frame-timing bugs, because the property itself is what's changing, not an unrelated transform standing in for it.

box-sizing: content-box vs border-box, made visibly concrete

This is the part that actually resolves real confusion. The content box has a fixed base size (CONTENT_W = 200, CONTENT_H = 100) representing a CSS width/height declaration. In content-box mode (the CSS default), that 200px width describes the content area only — padding and border are added on top, so the total rendered footprint grows every time you increase padding or border. In border-box mode, the exact same 200px width is reinterpreted as the *total* footprint including padding and border, so render() subtracts the current padding and border from 200 to compute the shrunken content box width (clamped to a 20px floor so it never inverts). Toggling the segmented control replays both interpretations against the identical padding/border values you've already dialed in, and the "Rendered total" readout below the stage prints the actual final footprint in both modes — the exact number a real layout bug report would hinge on.

Live pixel labels instead of a separate readout panel

Each layer overlays four small absolutely-positioned .val spans, one per side, showing that side's current pixel value directly on the layer itself (top value at the top edge, left value at the left edge, and so on) rather than in a separate legend the user has to cross-reference. This keeps the spatial relationship between "this number" and "this visible band of color" immediate, which matters because the entire point of the component is connecting a slider value to where it physically shows up on screen.