Payload CMS Layout Blocks vs Lexical Blocks: The Real Difference

What is a Layout Block?

Payload's Blocks field stores an array of objects where each object is a block with its own schema. Different block types can be mixed and reordered.

Page
└── layout[]
    ├── Hero
    ├── FeatureGrid
    ├── Gallery
    └── CTA

Each block has its own configured fields.

Hero
├── heading
├── description
├── image
└── buttons[]

Payload fields define the stored document schema and the corresponding Admin UI, which makes a normal Blocks field a very explicit content structure.

What is a Lexical Block?

A Lexical rich-text field stores its content as JSON representing the editor state and its tree of nodes. With BlocksFeature, Payload blocks can be inserted directly into that rich-text structure.

Post
└── content: richText
    └── Lexical document
        ├── Heading
        ├── Paragraph
        ├── Paragraph
        ├── Payload Block
        │   └── Gallery
        ├── Paragraph
        └── Payload Block
            └── CTA

A normal block belongs to a Blocks field. A Lexical block belongs to the Lexical document tree.

The same block can be used in both

Payload does not require separate block architectures for Layout Blocks and Lexical Blocks. A block definition can be reused in a normal Blocks field and supplied to BlocksFeature.

GalleryBlock
     │
     ├── used in page.layout
     │
     └── used inside richText

The block schema can remain the same while the rendering context changes.

Editing experience

Layout Blocks

A normal Blocks field presents the editor with a sequence of discrete blocks.

Hero
Feature Grid
Gallery
Testimonials
CTA

Editors are mainly changing fields such as headings, text, images, links, options and arrays. Payload also supports block-specific Admin components and labels.

The practical advantage is that the structure is direct and easy to understand.

Lexical Blocks

Lexical starts from a document editing model. Blocks can exist between or alongside headings, paragraphs and other rich-text nodes.

Heading

Paragraph

[Gallery Block]

Paragraph

[Interactive Block]

Paragraph

Payload's Lexical editor also allows customisation of the slash menu, toolbars, components and subfields.

Why Lexical Blocks can be more versatile

The main practical difference is context. A Lexical block is rendered from inside a rich-text structure rather than as a top-level layout entry.

article
└── rich-text wrapper
    ├── paragraph
    ├── paragraph
    ├── block wrapper
    │   └── Gallery
    ├── paragraph
    └── heading

From a CSS perspective, the block is part of that surrounding layout context. This does not mean properties such as width or height are automatically inherited. Instead, the component is subject to ancestor layout constraints.

• max-width
• padding
• grid context
• flex context
• overflow
• positioning context
• CSS variables
• container queries
• theme classes
• ancestor selectors

This is ordinary browser layout behaviour caused by DOM nesting. Lexical simply creates a useful place for that nesting to occur.

CSS control

Because a Lexical block appears inside a document structure, developers can style it based on its surrounding context.

.article-content .gallery-block {
  max-width: 60rem;
}

.article-content .gallery-block[data-variant='wide'] {
  width: 120%;
  margin-left: -10%;
}

.dark-section .gallery-block {
  --gallery-background: #111;
}

The block can share the layout rules of its parent while still being independently targeted.

The downside: deeper nesting

The same nesting that gives Lexical Blocks flexibility also makes the frontend structure more complex.

Page
└── Layout Block
    └── Content wrapper
        └── RichText
            └── Lexical node
                └── Payload Block
                    └── Block component
                        └── Child components

That matters because CSS and layout behaviour depend on ancestors.

• a parent max-width constrains the block
• a parent overflow: hidden can clip it
• a transformed ancestor can affect positioning
• position: sticky depends on scroll and overflow ancestors
• selectors higher in the tree can affect descendants
• deeply nested components can become harder to debug

Those are browser and CSS behaviours, not Payload-specific limitations. The practical consequence is that Lexical Blocks require more frontend awareness.

Data structure

Layout Blocks

Payload documents the Blocks field as an array of block objects.

{
  "layout": [
    {
      "blockType": "hero",
      "heading": "Example"
    },
    {
      "blockType": "gallery",
      "images": []
    }
  ]
}

Lexical Blocks

Payload rich-text fields save their state as JSON. A block inside Lexical exists as part of that serialized rich-text structure.

{
  "root": {
    "children": [
      {
        "type": "paragraph"
      },
      {
        "type": "block",
        "fields": {
          "blockType": "gallery"
        }
      }
    ]
  }
}

Custom blocks inside Lexical also need corresponding rendering logic when converting rich-text content.

Database impact

MongoDB

Payload stores a document as one MongoDB document even when it contains arrays or Blocks fields.

Postgres and SQLite

Payload's SQL adapters provide a blocksAsJSON option. With that option enabled, block data is stored in a JSON column instead of using Payload's normal relational block structure.

Normal Blocks field on SQL
→ normally relational block storage

blocksAsJSON enabled
→ JSON storage

Lexical rich text
→ JSON

Payload does not publish a universal benchmark proving that Layout Blocks or Lexical Blocks are inherently faster. Any blanket statement that one is always faster would be unsupported.

Rendering

Payload provides converters for Lexical content including JSX, HTML, plaintext, Markdown and MDX. Custom blocks inside Lexical need corresponding custom rendering logic.

blockType
→ React component

Lexical node
→ converter / renderer
→ React component

That is a structural difference. It does not by itself prove a meaningful frontend performance difference. The final browser cost still depends primarily on what the rendered components contain.

Customisation

Layout Blocks

Payload allows block-level Admin customisation, including custom Block and Label components. You can also build arbitrary field schemas inside each block.

Lexical

Payload exposes deeper editor-level configuration, including:

• slash menus
• inline toolbars
• fixed toolbars
• custom components
• custom subfields

Both systems are highly customisable. The difference is where the customisation happens.

Practical trade-off

Lexical Blocks can be extremely flexible, but the surrounding DOM, CSS and rendering structure becomes more important. Layout Blocks remove much of that complexity by keeping sections explicit and separate.

A more realistic comparison

Page
└── Gallery

Page
→ Block
→ Component

Page
└── Content
    └── RichText
        └── Gallery

Page
→ Content
→ RichText
→ Lexical node
→ Block
→ Component

Neither is inherently better. The second architecture simply gives the component more surrounding context to interact with.

Summary