Drupal Layout Builder vs Paragraphs: Choosing a Page Composition Model

If you're building editor-controlled landing pages in Drupal 9, 10, or 11, you face one structural decision early: do editors compose pages with core Layout Builder, or with the contributed Paragraphs module? Both are actively maintained and widely deployed, but they model content very differently, and switching later is expensive. This guide compares the two, explains the trade-offs, and ends with a prototype validation you can run in a day.

The decision and its constraints

The real question is not "which is better" but "which data model fits your editorial workflow." Layout Builder treats a page as a layout of blocks stored against the entity or its display. Paragraphs treats a page as an ordered list of typed, fieldable component entities referenced from the host node. Constraints that usually decide it:

• Reuse: must a composed section (say, a configured card grid) be shared across multiple pages?
• Component governance: do you need a fixed design-system vocabulary of typed components with their own fields?
• Dependency risk: how much contrib surface can your upgrade process absorb?
• Delivery channel: is the site rendered by Drupal, or consumed through JSON:API by a decoupled front end?

Comparison at a glance

Trade-offs that matter in practice

Editorial control vs. structural governance

Layout Builder gives editors freedom: drag blocks into sections, override a single page's layout without touching code. That freedom is also its weakness. Two editors will build the "same" hero two different ways, and nothing enforces a component vocabulary. Paragraphs enforces structure: you define a Hero paragraph type with exactly the fields a hero may have, and editors pick from your approved types. For design-system-driven teams, that governance is usually the deciding factor.

Dependency and upgrade surface

Layout Builder has zero contrib dependencies, which reduces major-version upgrade friction. Paragraphs is well maintained, but it is still a dependency whose release line you must track against your core version — confirm the recommended branch before committing, since this changes over time. Paragraphs also adds tables and entity references, which makes content migrations and bulk updates more involved: updating a field across 5,000 hero paragraphs is an entity operation, not a node update.

Decoupled delivery

If the site is API-first, this often tips the decision on its own. Paragraphs content serializes naturally through JSON:API as included referenced entities, so a front end can map paragraph types to components one-to-one. Layout Builder layouts have historically required additional contrib modules or custom normalizers to expose cleanly over an API. Verify this against your core version — the ecosystem moves — but plan for extra work if you go headless with Layout Builder.

One rule regardless of choice

Do not mix both composition models on the same content type. Editors get two competing UIs for the same job, and any future migration has to untangle both. Pick one model per content type; using Paragraphs for article body components and Layout Builder for a separate campaign landing type is fine.

Concrete validation: a one-day prototype

Build the same three representative components — a hero, a text-plus-media section, and a card grid — in both approaches on two fresh installs matching your target core version, then score them.

1. Layout Builder prototype: On a fresh install, enable the Layout Builder and Layout Discovery modules. On a test content type, go to Manage display, enable "Allow each content item to have its layout customized," and confirm an editor can override the layout on an individual node and place the three components as blocks.
2. Paragraphs prototype: On a separate install, add the Paragraphs module with Composer (composer require drupal/paragraphs, requires Drush or admin UI to enable). Create Hero, Text+Media, and Card Grid paragraph types, add a paragraphs field to a test node type, and verify reordering, nesting (cards inside the grid), and translation if you need it.
3. Editorial test: Have an actual editor assemble the same page in both. Count the steps. Then ask them to reuse the card grid on a second page — this is where Layout Builder's weakness shows up immediately.
4. API test: Enable JSON:API on both and fetch a page (/jsonapi/node/<type>/<uuid>?include=<paragraphs_field> on the Paragraphs site). Compare whether the output shape is something your front end can consume directly.
5. Deployment test: Run drush cex on both sites and inspect what configuration was exported. Confirm your team is comfortable with how Layout Builder overrides versus Paragraphs types will move between environments.

Limitations and how to check your result

This comparison reflects well-established behavior in Drupal 9/10/11, but contrib ecosystems change: check the current Paragraphs release line and the state of Layout Builder API exposure for your exact core version before final commitment. Neither prototype proves performance at scale — if you expect tens of thousands of paragraph entities, load-test separately. The decisive check is simple: if the editor in step 3 completed the Paragraphs page with fewer errors and the reused section worked without copy-paste, structure wins; if the editor needed ad-hoc freedom the component types couldn't express, Layout Builder wins.