Visual layout builder for CSS Flexbox and Grid where the generated CSS is the same declaration list the preview applies, checked to the pixel: twelve presets, the track list read against the CSS Grid grammar, and anything the browser will drop named
Related reading
Initializing in your browser…
Build a CSS keyframe animation with the timing function held to what the specification allows: named, cubic-bezier and steps easings, a preview built from the same declarations as the copied CSS, and every problem the browser would refuse named before you paste it
Build a clip-path from polygons, circles, ellipses and rounded insets, with the fill rule exposed and the value checked before it is shown
Frosted glass CSS where every setting can be set to zero, any colour notation works, and the reason backdrop-filter renders flat on a real page is written down
You want a navbar with the logo pinned left, links centered, and a button hard right, and you keep guessing flex properties.
Layout chosen
display flex · justify-content space-between · align-items center · gap 1rem
Generated CSS
.nav {
display: flex;
justify-content: space-between;
align-items: center;
gap: 1rem;
}`justify-content: space-between` pushes the first and last children to the edges with free space distributed between them, while `align-items: center` handles vertical centering, the exact recipe for a navbar. The playground shows real boxes responding as you toggle properties, so you learn which property does what instead of memorising, then copy the CSS that matches the preview.
Interactive controls for every flexbox and grid property, with the CSS it writes being the same declarations the preview applies, checked to the pixel rather than asserted.
Flexbox and Grid each have more than a dozen properties that interact in ways no amount of reading settles, which is what a playground is for. This one is built around a single rule: the CSS in the Code tab is the SAME list of declarations the Preview applies, and that identity is checked rather than asserted. The driver copies the generated rule onto a fresh element tree with the same children at the same container width and compares getBoundingClientRect for every item against the playground's own; nothing ships until all of them agree to within half a pixel across all twelve presets.
That check exists because the previous version failed it. Measured on 2026-09-04, 38 of 54 items across its eleven presets landed somewhere other than where it had drawn them, for two separate reasons. It applied declarations to the preview that it never wrote down: every flex item carried an 80px minimum width and height and 12px by 16px of padding inline, and the generator emitted the minimums only when they differed from the default and the padding never, so a default item was 80 by 80 on screen and content sized in the code. And a React style object holding an undefined key destroyed every grid span: setting grid-column to span 12 writes both grid-column longhands, and a gridColumnStart key with no value one line later removed the start again, leaving grid-column-end: auto and an item one column wide where the CSS said twelve.
Beyond that, the free-text track list is read against the grammar in CSS Grid Layout Level 2 section 7.2 rather than passed through, so the page can say `12 columns` for repeat(12, 1fr), say that repeat(auto-fill, ...) depends on the container width, and refuse minmax(1fr, 2fr) by name (section 7.2.1: the first argument is an inflexible breadth). It also names the two things that look like layout choices and are not: align-content on a nowrap container, which aligns lines and there is only one, and justify-content beside a growing item, which has no free space left to distribute. A span wider than the explicit grid is reported with what the browser really does, measured rather than assumed: it does not clamp the span, it adds implicit columns sized by grid-auto-columns.
Understand how flexbox and grid properties work by experimenting with live visual feedback.
Quickly build a layout structure and grab the CSS instead of trial-and-error in a code editor.
Demonstrate layout concepts to students or teammates with an interactive visual tool.
Reproduce a layout problem in the playground to understand which property is causing unexpected behavior.
Flexbox is for one dimension, a row or a column, where the content sizes decide the layout. Grid is for two dimensions at once, where you decide the tracks and the content fits into them. The Card Grid and 3-Column presets here are the same layout done both ways, and the flexbox one needs a calc() to subtract the gap share while the grid one does not.
Yes, and it is the usual arrangement: Grid for the page, Flexbox for what sits inside a cell. A grid item is itself a block, so giving it display: flex changes nothing about its placement.
Nothing: it adds space between items and never at the edges in both. The difference is what it interacts with. In a flex container the gap comes out of the free space that justify-content would otherwise distribute, so a gap plus space-between is often not what people expect.
Not because of this tool, which emits every declaration the preview applies and is checked against its own preview to within half a pixel. The usual causes are a different container width, since a layout is a function of the space it is given, and children with content of a different size, since flex-basis: auto and grid auto tracks are content sized.
Because the browser does not clamp the span. Measured in Chrome: a span 12 item in a three-track grid makes nine implicit columns, sized by grid-auto-columns, which is auto, so an empty one is zero wide. The item looks full width and the grid quietly has twelve tracks. The page says so when it happens.
This runs as client-side JavaScript. Keys, tokens, payloads, and other inputs never leave your device.