Flexbox Alignment Visualizer — Free HTML CSS JS Snippet

Flexbox's alignment properties are simple individually and confusing together, mostly because justify-content and align-items behave differently depending on flex-direction — the property that controls "horizontal spacing" swaps to controlling "vertical spacing" the moment you flip from row to column, and most static documentation diagrams only ever show one direction. This snippet lets you change all four properties live on a real flex container with five visibly distinct, differently-sized boxes, animating every reflow so you can watch the relationship between the values and the result rather than re-reading a table of definitions.

Real flex properties, not a simulated layout

The stage element (#stage) is an actual display: flex container. Every control in the panel is a button that, on click, writes directly to stage.style.justifyContent, stage.style.alignItems, stage.style.flexDirection, or stage.style.flexWrap — there is no separate rendering layer computing box positions manually. This matters pedagogically: what you see is exactly what the browser's flex layout algorithm produces for those exact property values, so the intuition transfers directly to a real stylesheet with zero translation.

Data-driven control rows, one function for all four properties

Rather than writing four separate button-generation blocks, buildRow(containerId, prop, options) is called once per property with an array of valid CSS values (JUSTIFY, ALIGN, DIRECTION, WRAP) and builds a row of toggle buttons from it. Every button's click handler calls the same setProp(prop, value, row), which updates the shared state object, toggles the .active class on the clicked button within its row, and calls render(). This means the four control groups share one code path end to end — adding a fifth property like align-content (relevant once wrapping is enabled) is one more array and one more buildRow call, not four new functions.

Why the boxes are deliberately different sizes

Boxes 3, 4, and 5 are given explicit non-default heights and widths (.b3 is taller, .b4 is wider, .b5 is shorter) instead of all five boxes being identical squares. This is intentional: align-items: stretch (the flexbox default) only becomes visually obvious when the boxes don't already share a height, and align-items: baseline only makes sense to look at when items are different sizes. A row of uniform squares would make several of the six justify-content values and several of the five align-items values look almost identical to each other, which defeats the entire point of the visualizer.

Genuine animation via CSS transitions on the boxes themselves

Each .box declares transition: transform 0.32s cubic-bezier(0.4,0,0.2,1), margin 0.32s cubic-bezier(0.4,0,0.2,1). Because the flex layout algorithm recalculates each box's final position as an internal transform/offset when justify-content, align-items, flex-direction, or flex-wrap changes, and modern browsers animate flex-driven position changes on the child elements smoothly as long as a transition is declared on the children (not the container, whose display and layout-mode properties are not smoothly animatable), the reflow between any two states plays as a fluid slide rather than an instant snap. This was verified directly rather than assumed: toggling flex-direction from row to column produces a full diagonal glide of every box to its new slot, not a jump-cut, because the child boxes — not the flex container — are what's carrying the transition.

The code readout is illustrative, not a generator

Beside the stage, a dark-background <pre>-style panel prints the current values of all four properties as real CSS syntax, color-coded (blue property names, green values) the way a syntax-highlighted editor would render them. This exists purely so the mapping between "the button I clicked" and "the CSS property name and value it corresponds to" is always visible without opening DevTools — it re-renders on every setProp call by rebuilding a template string, the same state object driving both the live layout and the readout text so the two can never fall out of sync.