CSS Flexbox Generator

Getting the Axis Right Before Touching Anything Else

• Decide flex-direction first, before justify-content or align-items. Those two properties literally swap which axis they control between row and column — tuning alignment before direction is settled usually means redoing it once direction changes.
• Reach for gap before margins on individual items. Gap only adds space between items, never at the container's outer edge — exactly the spacing bug hand-rolled item margins usually create, with extra space on the first or last item that then has to be manually removed.
• Use flex-shrink: 0 on anything that must never compress. Icons and fixed-width badges look visibly broken the moment a shrink value above zero lets them get squeezed in a tight row.
• Pair basis with grow: 0 and shrink: 0 for a genuinely fixed size. Basis alone is only a starting point — grow or shrink left at their defaults can still resize the item away from it.

Features

Two Axes, One Set of Properties That Keep Swapping Meaning

Flexbox thinks in exactly two axes — a main axis and a cross axis — and flex-direction decides which physical direction each one points. Set direction to row and the main axis runs horizontally, which is why justify-content (a main-axis property) spaces items left to right while align-items (a cross-axis property) controls their vertical position. Switch direction to column and the two axes rotate with it: justify-content now controls vertical spacing and align-items controls horizontal position, even though neither property's name changed at all. This is the single most common source of "flexbox isn't working" confusion — the properties didn't stop working, the axis they're measured against just rotated 90 degrees. Flex-wrap adds a third wrinkle on top of this: once a container is allowed to wrap onto more than one line, align-items still governs how each item sits within its own line, but align-content takes over deciding how the lines themselves are spaced relative to each other — two different questions that happen to sound similar enough to get mixed up in practice.

Why Grow and Shrink Aren't Opposites

It's tempting to think of flex-shrink as flex-grow running in reverse, but they solve two genuinely different problems. Flex-grow only ever distributes leftover space — space that exists because every item's combined basis adds up to less than the container's width. If the items already fill the row exactly, grow has nothing to distribute no matter how high its value is set. Flex-shrink does the opposite job: it only activates when items collectively overflow the container, removing space proportionally so everything still fits on one line instead of forcing a scrollbar or a broken layout.

Both values are weighted, not absolute, which is the part that trips people up first. An item with grow: 2 doesn't grow to exactly twice any fixed amount — it gets roughly twice the share of leftover space that an item with grow: 1 gets, and if every item in the row has grow: 1, they all end up equal regardless of their starting basis. That's why two items with wildly different basis values but the same grow number can still end up nearly the same final width once the container has enough free space to work with.

align-items, align-self, and the One-Off Exception

align-items sets the default cross-axis position for every item in the container in one declaration — center them all, stretch them all, line them all up along their baselines. The moment a single item needs to break that pattern, align-self overrides the default for just that one item without touching anything else, which is the correct tool for exactly one situation: a lone badge, icon, or call-to-action that should sit differently than its siblings rather than forcing the whole row's alignment to accommodate one exception.

Presets as Named Patterns, Not Just Shortcuts

Sidebar + Main and Wrap Grid aren't arbitrary configurations — they're the same two or three layouts that show up in the vast majority of real interfaces, given a name instead of being rebuilt from a blank container every time. Loading Sidebar + Main sets one item to a fixed basis with no grow and the other to grow: 1 in a single click — the exact relationship that makes a sidebar hold its width while the main content area fills whatever space is left, which is a two-property interaction that's easy to get backwards when set up by hand for the first time — a sidebar left at the default grow: 0 but missing shrink: 0 too will still quietly compress the moment the window narrows, which is exactly the kind of edge case a named preset gets right by default instead of leaving it to be discovered later on a smaller screen.

Treating a preset as a starting point rather than a fixed answer is still the right instinct, though. Applying Wrap Grid and then adjusting gap or a single item's basis to fit actual content is normal and expected — the preset's job is to skip the part where every layout starts from an empty container and a blank guess, not to lock the result to one specific look.

Reading Clean CSS Output Instead of a Wall of Defaults

An item left at every default value is already behaving exactly like a plain, unstyled flex item — writing a rule that just restates order: 0 and flex-shrink: 1 for it would be pure noise in the exported stylesheet. Only items where something has actually been changed from its default get their own .item-N block, so the CSS handed back always matches what the layout genuinely needs rather than padding every item with redundant declarations a reader would have to mentally filter out.

The shorthand toggle exists for the same reason in a different spot: three separate lines — flex-grow, flex-shrink, flex-basis — are easier to scan while tuning a layout, but the single flex: G S B shorthand is what most production stylesheets and minified CSS actually ship, since it's shorter and behaves identically. Leaving shorthand on by default matches what a component library or a formatted stylesheet is more likely to already contain.

From a Tuned Container to a Real Component

A typical path: pick a preset close to the target layout — Space Between for a navbar, Sidebar + Main for an app shell, Wrap Grid for a card gallery — then adjust individual items where the preset doesn't quite match, like giving one card a larger basis or pulling a single badge out of the row's default alignment with align-self. Once the numbers look right in the preview, copying the CSS output straight into a stylesheet is the entire rest of the job; if the same component also needs a background or a shadow, pairing this with the gradient generator or the box shadow generator keeps every visual property of the component tuned in the same session instead of switching context between separate tools later.

Frequently Asked Questions