The module that lets Drupal editors build pages from reusable components instead of one giant body field. Still the default for structured, component-based content.
Paragraphs is the module most Drupal marketing sites lean on for editor-friendly page building. Instead of one giant body field, you give editors a set of components (a hero, a text-and-image block, a call to action) that they add, reorder, and fill in. It has been around since Drupal 7 and it is still the default answer for structured, component-based content.
This is the real decision, and most tutorials skip it. Paragraphs gives editors structured components inside a field; Layout Builder gives them free-form control over the whole page layout. If you want editors to assemble approved building blocks without touching the design, Paragraphs wins. If you need them to drag blocks into arbitrary regions and columns, Layout Builder fits better. Plenty of sites use both: Layout Builder for the shell, Paragraphs for the content inside it, or Layout Paragraphs to get drag-and-drop on top of Paragraphs.
Two places, mostly. Translation is fiddly because Paragraphs ride on Entity Reference Revisions, so multilingual sites need careful configuration or translations drift. And deep nesting has a real performance cost: paragraphs inside paragraphs inside paragraphs generate a lot of revision rows and entity loads. We keep nesting shallow and prune old revisions on sites that have run for years.
We treat Paragraphs as a locked-down component library. Editors get exactly the components the design supports, with sensible field validation, so nobody can break the layout by accident. When editors need to rearrange components visually, we add Layout Paragraphs. It plugs into the same theme work we do on Twig and Single Directory Components.
Once your Paragraphs content grows, people need to find it. That is where the Search API module comes in.
Define paragraph types (hero, text and image, CTA) once and let editors reuse them across the site.
Editors add, remove, and reorder components without a developer and without touching the design.
Each paragraph type is a real entity with its own fields, validation, and display settings.
Pair it with Layout Paragraphs for drag-and-drop, multi-column editing on top of the same components.
We use this in real client projects — here's what we've learned.
For component-based content that editors manage themselves, Paragraphs is still the default choice on Drupal. Reach for Layout Builder when editors need free-form page layout, and combine the two when you need each. Keep nesting shallow and plan translation up front.
Paragraphs for structured components editors fill in; Layout Builder for free-form page layout. Many sites use both. If your editors should assemble approved blocks without touching the design, start with Paragraphs.
Yes. It is actively maintained and supported on Drupal 9, 10, and 11, so it is a safe long-term choice.
Only when you nest it deeply. Each level adds revision rows and entity loads. We keep the component tree shallow and prune old revisions, and performance is a non-issue.
Yes, out of the box. Add Layout Paragraphs and they get drag-and-drop with multi-column layouts.
Manageable, but it needs planning. Paragraphs use Entity Reference Revisions, so multilingual sites must be configured carefully from the start to avoid drift.
We can install, configure, or customize it for you.
Don't want to install yourself? Our developer connects via FTP, installs, configures, tests with a real transaction. Usually takes one business day.
