Bento Grid Design: The CSS Recipe for Feature Pages

Bento grid design is a layout pattern inspired by compartmentalized Japanese lunchboxes, where content is organized into variable-sized tiles within a CSS Grid structure. Each tile occupies one or more grid cells, creating a visually weighted composition that lets users scan features, media, and data points without a rigid column hierarchy. It is used primarily on product and feature marketing pages to present multiple content types -- text, images, video, stats -- in a single scannable viewport.

TL;DR

Bento grids work because they match how people actually consume feature pages: scanning, not reading. The CSS is straightforward -- grid-template-columns, grid-template-rows, and named grid-area values. The hard part is content-first sizing, managing visual weight across tiles, and reflowing gracefully on mobile with grid-auto-flow: dense. This article covers all of that with production CSS you can copy.

Why do bento grids work so well on feature pages?

Bento grids solve a specific UX problem: feature pages need to present 6-12 distinct selling points without forcing users into a long scroll of identical cards. A bento layout gives visual hierarchy to a heterogeneous set of content blocks, letting the most important feature occupy a 2x2 tile while supporting details sit in 1x1 tiles around it.

I ran into a Reddit thread where u/ash_burnham argued that bento grids "mess up hierarchy" because it's "very difficult to nail the hierarchy when working with them." I disagree, but only when you approach the layout content-first rather than aesthetics-first. If you start by deciding which feature is your hero, which are secondary, and which are tertiary, the grid template writes itself. I sketch out a spreadsheet of features ranked by business priority before touching Figma or CSS.

Another commenter, u/pip-whip, pushed back harder: "Design shouldn't be formulaic. You should be making choices that best represent your message and your content." They're right. A bento grid is a structural pattern, not a style. The boxes with rounded corners that everyone associates with bento are just one visual treatment. I've shipped bento layouts with sharp edges, overlapping tiles, and tiles that bleed outside the grid boundary. The pattern is the variable-sized compartments, not the aesthetic.

Where bento grids outperform alternatives

Layout Pattern	Best For	Weakness on Feature Pages
Single-column stack	Blog posts, documentation	Every feature looks equally important
Two-column alternating	Case studies, about pages	Repetitive rhythm, hard to feature media
Masonry (Pinterest-style)	Image galleries	No intentional hierarchy, content determines size
Bento grid	Feature/product pages	Requires deliberate content-weight planning

Apple's MacBook Pro and Vision Pro landing pages are the most cited examples for a reason. They demonstrate a principle I keep returning to: the grid serves the content, not the other way around.

What exactly is a bento grid in CSS terms?

A bento grid is a CSS Grid layout where child elements span different numbers of rows and columns, creating an asymmetric but deliberate tile arrangement. Unlike a uniform card grid (e.g., repeat(3, 1fr)), a bento grid uses explicit placement via grid-column and grid-row span values, or named grid-template-areas.

The MDN CSS Grid Layout guide covers the full specification, and the sections on explicit vs. implicit grid behavior are worth reading. Bento grids are almost always explicit -- you define exactly where each tile goes. Implicit grid behavior (where the browser decides placement) leads to the kind of hierarchy problems u/ash_burnham was worried about.

Here's the minimal mental model:

• Grid container: The bento box itself
• Grid items: The compartments (tiles)
• Grid tracks: The rows and columns that form the structural lines
• Grid areas: Named regions that tiles occupy

Chris Coyier's "A Complete Guide to CSS Grid" on CSS-Tricks is the best single reference for the properties involved. I keep it bookmarked and reference it during every grid-heavy build.

What is the CSS Grid template recipe for bento layouts?

The recipe is a 4-column, auto-row grid with named template areas. Here's what I use on feature pages:

.bento {
  display: grid;
  grid-template-columns: repeat(4, 1fr);
  grid-template-rows: auto;
  gap: 1rem;
  max-width: 1200px;
  margin: 0 auto;
  padding: 1rem;
}

That gives you the container. Now the tiles:

/* Hero tile -- spans 2 columns and 2 rows */
.bento__tile--hero {
  grid-column: span 2;
  grid-row: span 2;
}

/* Wide tile -- spans 2 columns, 1 row */
.bento__tile--wide {
  grid-column: span 2;
}

/* Tall tile -- spans 1 column, 2 rows */
.bento__tile--tall {
  grid-row: span 2;
}

/* Standard tile -- 1x1, no special spanning */
.bento__tile--standard {
  /* inherits default 1-column, 1-row span */
}

Using named grid-template-areas

For tighter control -- and easier-to-read code -- I use named areas:

.bento {
  display: grid;
  grid-template-columns: repeat(4, 1fr);
  grid-template-rows: 280px 280px 200px;
  gap: 1rem;
  grid-template-areas:
    "hero  hero  feat1 feat2"
    "hero  hero  feat3 feat3"
    "feat4 feat5 feat6 feat6";
}

.bento__hero  { grid-area: hero; }
.bento__feat1 { grid-area: feat1; }
.bento__feat2 { grid-area: feat2; }
.bento__feat3 { grid-area: feat3; }
.bento__feat4 { grid-area: feat4; }
.bento__feat5 { grid-area: feat5; }
.bento__feat6 { grid-area: feat6; }

When you read the grid-template-areas value, you can literally see the layout. Debugging at 2am is much easier when the CSS looks like an ASCII art floor plan.

Row sizing: fixed vs. auto vs. minmax()

I use explicit row heights for above-the-fold bento sections and minmax() for content-driven sections:

/* Fixed rows for hero sections */
grid-template-rows: 300px 300px;

/* Content-adaptive rows */
grid-template-rows: minmax(200px, auto) minmax(200px, auto);

/* Combination */
grid-template-rows: 320px minmax(200px, auto) minmax(160px, auto);

Avoid 1fr for row heights in bento grids. It causes rows to stretch to fill available space, which breaks the visual weight you've carefully planned. Use auto or minmax() instead.

How do you balance tile weight in a bento grid?

Visual weight in a bento grid comes from four factors: tile size, background contrast, content density, and media presence. The hero tile should carry the most weight, and the arrangement should create a clear reading path -- typically an F-pattern or Z-pattern across the grid.

The weight framework

I use a mental prioritization tool (not a literal formula):

1. Size weight: A 2x2 tile has roughly 4x the visual pull of a 1x1 tile
2. Color weight: Dark backgrounds on light pages (or the reverse) pull attention
3. Media weight: Video > animated image > static image > icon > text-only
4. Density weight: A tile with a single stat ("99.9% uptime") reads faster than one with a paragraph

Practical tile-weight distribution

For a 7-tile bento on a feature page, I aim for:

Tile	Size	Content Type	Visual Role
Hero	2x2	Product screenshot + headline	Primary attention anchor
Feature A	2x1	Icon + short description	Secondary focus
Feature B	1x1	Single metric or stat	Quick-scan data point
Feature C	1x1	Icon + label	Quick-scan data point
Feature D	1x2	Tall image or illustration	Visual breather
Feature E	2x1	Testimonial or quote	Social proof
Feature F	1x1	CTA button or link	Conversion point

Literal's design uses bold typography against a muted color scheme -- that's color weight in action. The muted palette keeps secondary tiles from competing with the hero.

Weight mistakes I've made

• Equal-sized tiles everywhere: This turns a bento grid into a regular card grid. You lose the whole point.
• Too many hero tiles: If three tiles are all 2x2, nothing is the hero. One hero per viewport.
• Ignoring the diagonal: Place high-weight tiles so they create a diagonal or step pattern. This guides the eye naturally.

What does content-first sizing mean for bento tiles?

Content-first sizing means you determine what goes inside each tile before you decide how big it is. This sounds obvious, but in practice, most teams design the grid first and then try to fill it. That's backwards.

The content-first process I use

1. List every feature or content block you need on the page
2. Categorize each by content type: headline + body, stat + label, image + caption, video, etc.
3. Assign a priority tier: hero, secondary, tertiary
4. Map tiers to tile sizes: hero = 2x2, secondary = 2x1 or 1x2, tertiary = 1x1
5. Write the CSS grid template based on the mapping

This is the only reliable way to avoid treating bento as a visual trend to replicate rather than a structural tool to solve a content problem.

Handling overflow

Some content doesn't fit neatly into a tile. My rules:

.bento__tile {
  overflow: hidden;
  padding: 1.5rem;
  display: flex;
  flex-direction: column;
  justify-content: space-between;
}

.bento__tile p {
  display: -webkit-box;
  -webkit-line-clamp: 3;
  -webkit-box-orient: vertical;
  overflow: hidden;
}

If you're truncating more than one line regularly, the tile is too small for that content. Resize the tile, not the content.

How do you handle mobile reflow with grid-auto-flow?

Mobile is where most bento grids fall apart. A 4-column layout on desktop needs to become a 1- or 2-column layout on mobile, and the tile spanning needs to reset.

The reflow strategy

/* Mobile: single column, all tiles stack */
@media (max-width: 639px) {
  .bento {
    grid-template-columns: 1fr;
    grid-template-rows: auto;
    grid-template-areas: none; /* Reset named areas */
  }

  .bento__tile--hero,
  .bento__tile--wide,
  .bento__tile--tall {
    grid-column: span 1;
    grid-row: span 1;
  }
}

/* Tablet: 2 columns */
@media (min-width: 640px) and (max-width: 1023px) {
  .bento {
    grid-template-columns: repeat(2, 1fr);
    grid-template-areas:
      "hero  hero"
      "feat1 feat2"
      "feat3 feat3"
      "feat4 feat5"
      "feat6 feat6";
  }
}

grid-auto-flow: dense

The grid-auto-flow: dense property tells the browser to fill gaps in the grid by placing smaller items in holes left by larger spanning items. This is useful when your bento grid is generated dynamically (e.g., from a CMS) and you can't predict the exact arrangement.

.bento {
  grid-auto-flow: dense;
}

Caution: dense can reorder visual presentation, which breaks the relationship between DOM order and visual order. This is an accessibility problem. Screen readers follow DOM order, and keyboard tab order follows DOM order. If a tile visually appears second but is fifth in the DOM, sighted keyboard users will be confused.

My recommendation: use dense only for media-heavy grids (image galleries inside a bento section) where reading order doesn't carry semantic meaning. For feature pages with a deliberate narrative flow, define your areas explicitly and manage each breakpoint manually.

Tile aspect ratios on mobile

On mobile, 2x2 hero tiles that collapse to 1-column often become awkwardly tall. I use aspect-ratio to control this:

@media (max-width: 639px) {
  .bento__tile--hero {
    aspect-ratio: 16 / 9;
  }

  .bento__tile--standard {
    aspect-ratio: 4 / 3;
  }
}

aspect-ratio has been supported since Chrome 88 (January 2021), Firefox 89 (June 2021), and Safari 15 (September 2021). As of 2025, global support is over 95% per Can I Use, so it's safe in production.

Who does bento grid design well in production?

Rather than listing 20 examples with screenshots, here are the ones I've studied most closely and what makes each worth examining:

Apple (product feature pages)

Apple's MacBook Pro and iPhone feature pages are the canonical bento examples. Their tiles use full-bleed product photography, minimal text (often just a headline and a single stat), and dramatic background contrasts. What's less obvious: Apple's grids are not CSS Grid. They're built with absolutely positioned elements and JavaScript-driven scroll animations. For most teams, CSS Grid gets you 90% of the visual result at 10% of the complexity.

Linear (linear.app)

Linear's homepage uses a bento-style layout for feature presentation with dark tiles on a dark background. The differentiation between tiles comes from subtle border treatments and media type variation (some tiles have product UI screenshots, others have animated illustrations). Their mobile reflow is well-executed -- the grid collapses to a single column with each tile maintaining its content hierarchy.

Raycast (raycast.com)

Raycast's feature page uses a tight 3-column bento grid with consistent tile heights and varied column spans. What they do well: every tile has a single, clear purpose. No tile tries to do two things. This discipline is harder than it looks.

I browse Awwwards' "Sites of the Day" archive filtered by layout type to study tile-weight decisions in context.

What I build for clients

Bento grids show up in roughly 40% of the feature-page designs I ship for creative brands. The pattern works when a product has 5-8 distinct features that don't have a natural sequential order.

Performance and accessibility caveats

Bento grids introduce specific performance and accessibility concerns that you need to handle deliberately.

Performance

• Image-heavy tiles: Each tile on a bento grid often contains an image. A 7-tile bento section can mean 7 images loading above the fold. Use loading="lazy" on everything except the hero tile. Use fetchpriority="high" on the hero tile's image.
• Video tiles: If any tile contains autoplay video, use <video preload="none"> and trigger loading via Intersection Observer. A 3MB video in a bento tile that's below the fold on mobile will wreck your Core Web Vitals.
• CLS (Cumulative Layout Shift): Tiles without explicit dimensions (width, height, or aspect-ratio) will cause layout shifts as images load. Always set aspect-ratio or explicit grid-template-rows heights.
• LCP (Largest Contentful Paint): Your hero tile is almost certainly your LCP element. Optimize accordingly: use <img> with srcset and sizes, not CSS background-image. Preload the hero image in the <head>.

Accessibility

• Source order vs. visual order: grid-auto-flow: dense and manual grid-column/grid-row placement can reorder content visually without changing DOM order. I test with VoiceOver on macOS and NVDA on Windows to confirm the reading order makes sense.
• Focus order: Tab through your bento grid with a keyboard. If the focus indicator jumps from the top-right tile to the bottom-left tile, your DOM order doesn't match your visual order. Fix the HTML, not the CSS.
• Tile contrast: Dark-background tiles with light text need to meet WCAG 2.1 AA contrast ratios (4.5:1 for body text, 3:1 for large text). I run every tile through the axe DevTools browser extension during development.
• Semantic markup: Each tile should be a meaningful HTML element. I use <article>, <section>, or <figure> depending on the content. Don't make every tile a <div> -- give screen readers something to work with.
• Reduced motion: If tiles have entrance animations, wrap them in a prefers-reduced-motion media query:

@media (prefers-reduced-motion: reduce) {
  .bento__tile {
    animation: none;
    transition: none;
  }
}

FAQ

What is a bento grid in web design?

A bento grid is a CSS Grid layout where tiles span different numbers of rows and columns, inspired by the compartmentalized structure of Japanese bento boxes. It's used on feature and product pages to present varied content types in a single, scannable arrangement with intentional visual hierarchy.

Is a bento grid the same as a masonry layout?

No. Masonry layouts (like Pinterest) let content height determine tile size, creating a waterfall effect. Bento grids use deliberate, predefined tile sizes controlled by the designer. Masonry is content-driven; bento is design-driven. CSS Grid handles bento natively, while masonry requires JavaScript or the upcoming CSS masonry value.

Do bento grids hurt SEO?

Not inherently. The risk is source-order mismatch -- if your visually prominent hero tile is buried deep in the DOM, search engines may not weight its content correctly. Keep your HTML order aligned with content priority. Use heading levels (h2, h3) that reflect the visual hierarchy, not the DOM position.

How many tiles should a bento grid have?

I typically use 5-9 tiles per bento section. Fewer than 5 and a simpler layout works better. More than 9 and the visual weight becomes hard to manage -- everything starts looking the same size and importance. If you have 12+ features, split them into two bento sections with a content divider between them.

Can I build a bento grid with Flexbox instead of CSS Grid?

Technically yes, but it's painful. Flexbox is one-dimensional -- it handles rows or columns, not both. CSS Grid is purpose-built for two-dimensional layouts. Use Grid.

What CSS Grid browser support do I need?

CSS Grid (including grid-template-areas, gap, and subgrid) is supported in all modern browsers. Chrome, Firefox, Safari, and Edge have had full support since 2017-2018. The subgrid value (useful for aligning content across tiles) shipped in Chrome 117 (September 2023) and is now available everywhere except older mobile browsers. Check caniuse.com for your specific audience.

Did Apple or Microsoft invent the bento grid?

Neither invented it. Some designers trace the pattern to Microsoft's Metro design language in Windows Phone 7 (2010), while the current popularity wave started with Apple's WWDC 2020 slide designs. The pattern predates both -- variable-sized tile grids have existed in print design for decades. The name "bento" is recent branding of the pattern.