Layout Builder and Paragraphs solve different Drupal problems that often get described as the same one. Both can help editors assemble pages, but they put control in different places. The decision should start with the editorial workflow, not the module preference.
Use this comparison before a redesign, content model cleanup, or component-library build. The goal is not to crown one approach. The goal is to pick the model that gives editors enough freedom without turning every page into a one-off layout.
Use Layout Builder For Page-Level Placement
Layout Builder fits pages where editors need to place blocks, arrange sections, and make page-specific composition decisions. It is often useful for landing pages, campaign pages, and content types where the layout itself is part of the editorial task.
The tradeoff is governance. If every page can be assembled differently, the team needs clear defaults, section templates, allowed blocks, preview behavior, and regression checks. Otherwise the site slowly becomes a collection of special cases that are hard to theme and harder to maintain.
Use Paragraphs For Structured Content Patterns
Paragraphs works well when the site needs repeatable content sections: testimonial groups, feature rows, callouts, media-text blocks, comparison rows, or FAQ-like clusters. Editors choose from approved building blocks, while the design system keeps tighter control over markup and presentation.
For example, a case-study page might use Paragraphs for challenge, solution, metrics, quote, and gallery sections. The editor still has flexibility, but the components remain predictable enough for theming, accessibility review, and future migration.
A Hybrid Model Needs Rules
Many Drupal sites use both. That can be sensible when Layout Builder handles page placement and Paragraphs supplies structured components inside those placements. The hybrid approach fails when the same editorial need can be solved five different ways with no guidance.
Layout Builder vs Paragraphs: Decision Evidence Table
| Need | Better fit | Implementation note |
|---|---|---|
| Campaign page with custom section order | Layout Builder | Limit allowed blocks and provide starter layouts |
| Repeatable case-study sections | Paragraphs | Model fields around content meaning, not visual placement |
| Landing page using approved components | Hybrid | Document which layer owns spacing, headings, and media rules |
Worked implementation example: a university department wants flexible landing pages and repeatable research-story sections. Layout Builder can own the landing-page arrangement, while Paragraphs can own story components such as project summary, researcher quote, publication links, and impact metrics. That split keeps page order flexible but keeps the story data structured enough for theming, search, migration, and accessibility review.
Check The Maintenance Cost
Before deciding, review preview needs, translation, accessibility, component variants, permissions, caching, and future redesign work. Drupal.org documentation for Layout Builder and the Paragraphs project can anchor the technical discussion, while the site’s own editor training should decide how much choice is realistic.
The editor training burden is part of the architecture. If a small editorial team changes only a few pages each month, too many layout choices can create anxiety and inconsistent pages. If a publishing team builds campaign pages every week, a rigid Paragraphs-only model may create bottlenecks. The better choice is the one the team can operate cleanly after launch, not the one that looks most flexible in a demo.
For nearby planning work, see Drupal Pixels guides on component-library planning, content model cleanup, and editor experience checks.
Before implementation, prototype one real page in the preferred model and ask an editor to change it without developer help. Watch where they hesitate: choosing components, moving sections, finding preview, editing media, or understanding which fields affect layout. That test usually exposes the right governance rules faster than a long architecture debate.
Keep that prototype in the repository notes as a future regression example.