17 Tailwind CSS Dashboard Layouts

Demo 02 is the canonical shell: a two-column frame where the sidebar track animates between a full 236px rail and a 68px icon-only rail, with the main area staying fluid and reclaiming the freed pixels. Put the transition on the sidebar column width at the shell level, not on every child — one animation runs cleanly instead of each item fighting its own timing. Keep the icon and the text label as separate children inside each link so the label can fade out while the icon stays centred when the rail narrows; never collapse the whole <a> element or you lose the click target and the tooltip anchor. Toggle the collapsed state by flipping one class on the outer grid with a button, and let the grid-template-columns value swap do the work. Because the main pane is just the second track, nothing inside it has to know the sidebar moved.

Use container queries, which demos 03 and 08 are built on. Mark the wrapper as a query container with @container and give it a name, then size children with container variants like @min-[34rem]/kpi:grid-cols-4 instead of the viewport-based md: / lg: prefixes. In demo 03 the four KPI cards flow 4 to 2 to 1 columns purely from the width of their own grid, so the same component behaves correctly in a full-width page and in a narrow sidebar slot. Demo 08 proves the point by dropping one widget markup into three slots — narrow, medium, and a resizable one — and each renders a different layout at the same instant. The common mistake is forgetting to declare the container on the parent: the @min-[...] variants then silently never match, and the card falls back to its base layout with no error. Name your containers so nested queries resolve against the right ancestor.

A single h-screen on the outer frame is not enough — demos 16 and 05 show the real contract. The frame must be h-screen and overflow-hidden, every row inside it needs an explicit height or a min-h-0 so flex and grid children can shrink below their content, and only the one panel that is meant to scroll gets overflow-auto. The usual bug is a flex or grid child that refuses to shrink: by default it has min-height: auto, so its content forces the whole frame taller than the viewport and a page scrollbar appears. Add min-h-0 (and min-w-0 for horizontal cases) to that child. Demo 05 keeps the header and rails fixed while an inner activity feed scrolls independently; demo 16 kills every scrollbar for a wall display. If a stray bar persists, walk down the tree and find the row missing its min-h-0.

You do not need one, which is the whole point of demo 06. Define a normal grid with explicit column and row tracks using grid-cols-[...] and grid-rows-[...] on the shell, then place each region with col-span / row-span or the explicit col-start / row-start line utilities. The header spans the full top row, the sidebar takes the first column down the remaining rows, and the main and aside fill what is left — all addressed by grid lines rather than named strings. The advantage over real grid-template-areas is that you can re-place a region at a breakpoint by changing only its start/span utilities, with no second ASCII-art template to keep in sync. If you genuinely want named areas, use an arbitrary property like [grid-template-areas:...], but for a fixed header-sidebar-main shell the line-based approach reads more clearly and survives responsive changes better.

Demo 14 is the spreadsheet contract: the 10-column table scrolls both ways inside its panel while row one and column one stay pinned. Put overflow-auto on the panel wrapper, not the table. Give the header cells sticky top-0 and the first-column cells sticky left-0, and raise their z-index so they paint above the scrolling body — the top-left corner cell needs the highest z of all because it must sit above both the sticky row and the sticky column. The frequent bug is a transparent sticky cell: once the body scrolls under it you see both layers overlap, so every pinned cell needs a solid bg- utility matching the surface. Also give sticky cells a fixed width so the two axes agree on where the frozen column ends. sticky fails entirely if any ancestor has overflow: hidden on the wrong axis — the scroll container must be the direct overflow-auto parent.

Demo 10 treats dark mode as a data change, not a redesign. Every component uses semantic utilities only — tokens like bg-tdl10-card and a matching text token — so one attribute flip restyles the whole shell with no per-component dark variants scattered through the markup. The three-way control writes the choice: Light and Dark set an explicit attribute on the root, while System removes it and lets a prefers-color-scheme media query decide. The classic bug is a flash of the wrong theme on load because the attribute is applied after paint; set it from a tiny inline script in the document head before the body renders, reading the stored preference first. Persist the selection so a reload keeps it, and make sure System actually clears the override rather than hard-coding a value — otherwise the OS switching between light and dark at dusk does nothing. Build on tokens and you never touch a component when the palette changes.

Demo 07 shows one markup with two behaviours — in a wide panel the sidebar sits in-flow, in the phone frame it slides in as an off-canvas drawer — but the slide alone is not accessibility. The toggle must be a real <button> with aria-expanded reflecting open state and aria-controls pointing at the drawer, not a bare <div> with a click handler. When open on a narrow screen the drawer should trap focus so Tab cycles inside it, Esc should close it and return focus to the trigger, and the dimmed backdrop should be clickable to dismiss. Hide the off-screen drawer from the tab order when closed — a drawer translated off-canvas but still focusable lets keyboard users tab into invisible links. If you drive the whole thing with a checkbox for the zero-JS version, pair it with a <label> that is itself focusable and announce the state, because a raw checkbox hack gives screen readers no open/closed context.

Reach for demo 17, the top-bar-with-tabs pattern, when your app is shallow — a handful of primary sections rather than a deep tree. The GitHub and Stripe school drops the sidebar entirely: a global top bar plus a sticky tab strip with an animated underline gives every horizontal pixel to content, which suits reading-heavy and table-heavy pages. Prefer a sidebar (demos 02 and 11) once navigation grows past roughly seven destinations or needs nested groups, because a tab strip wraps or scrolls badly beyond that and multi-level nesting has nowhere to live. The off-canvas approach in demo 07 is the bridge for phone widths regardless of which you pick. Also avoid top-nav when you need persistent context — filters, a folder rail, a conversation list like the master-detail inbox in demo 04 — since those want a column that stays put. Match the chrome to the depth of the information architecture, not to a visual preference.