Rich Text Editor

The editor is the most important property of the rich text field.

As a key part of Payload, we are proud to offer you the best editing experience you can imagine. With healthy defaults out of the box, but also with the flexibility to customize every detail: from the “/” menu and toolbars (whether inline or fixed) to inserting any component or subfield you can imagine.

To use the rich text editor, first you need to install it:

1pnpm install @payloadcms/richtext-lexical

Once you have it installed, you can pass it to your top-level Payload Config as follows:

1import { buildConfig } from 'payload'
2import { lexicalEditor } from '@payloadcms/richtext-lexical'
3
4export default buildConfig({
5  collections: [
6    // your collections here
7  ],
8  // Pass the Lexical editor to the root config
9  editor: lexicalEditor({}),
10})

You can also override Lexical settings on a field-by-field basis as follows:

1import type { CollectionConfig } from 'payload'
2import { lexicalEditor } from '@payloadcms/richtext-lexical'
3
4export const Pages: CollectionConfig = {
5  slug: 'pages',
6  fields: [
7    {
8      name: 'content',
9      type: 'richText',
10      // Pass the Lexical editor here and override base settings as necessary
11      editor: lexicalEditor({}),
12    },
13  ],
14}

Extending the lexical editor with Features

Lexical has been designed with extensibility in mind. Whether you're aiming to introduce new functionalities or tweak the existing ones, Lexical makes it seamless for you to bring those changes to life.

Features: The Building Blocks

At the heart of Lexical's customization potential are "features". While Lexical ships with a set of default features we believe are essential for most use cases, the true power lies in your ability to redefine, expand, or prune these as needed.

If you remove all the default features, you're left with a blank editor. You can then add in only the features you need, or you can build your own custom features from scratch.

Integrating New Features

To weave in your custom features, utilize the features prop when initializing the Lexical Editor. Here's a basic example of how this is done:

1import {
BlocksFeature,
LinkFeature,
UploadFeature,
lexicalEditor,
6} from '@payloadcms/richtext-lexical'
7import { Banner } from '../blocks/Banner'
8import { CallToAction } from '../blocks/CallToAction'
9
10{
editor: lexicalEditor({
  features: ({ defaultFeatures, rootFeatures }) => [
    ...defaultFeatures,
    LinkFeature({
      // Example showing how to customize the built-in fields
      // of the Link feature
      fields: ({ defaultFields }) => [
        ...defaultFields,
        {
          name: 'rel',
          label: 'Rel Attribute',
          type: 'select',
          hasMany: true,
          options: ['noopener', 'noreferrer', 'nofollow'],
          admin: {
            description:
              'The rel attribute defines the relationship between a linked resource and the current document. This is a custom link field.',
          },
        },
      ],
    }),
    UploadFeature({
      collections: {
        uploads: {
          // Example showing how to customize the built-in fields
          // of the Upload feature
          fields: [
            {
              name: 'caption',
              type: 'richText',
              editor: lexicalEditor(),
            },
          ],
        },
      },
    }),
    // This is incredibly powerful. You can re-use your Payload blocks
    // directly in the Lexical editor as follows:
    BlocksFeature({
      blocks: [Banner, CallToAction],
    }),
  ],
})
54}

features can be both an array of features, or a function returning an array of features. The function provides the following props:

Prop	Description
`defaultFeatures`	This opinionated array contains all "recommended" default features. You can see which features are included in the default features in the table below.
`rootFeatures`	This array contains all features that are enabled in the root richText editor (the one defined in the payload.config.ts). If this field is the root richText editor, or if the root richText editor is not a lexical editor, this array will be empty.

Features overview

Here's an overview of all the included features:

Feature Name	Included by default	Description
`BoldFeature`	Yes	Handles the bold text format
`ItalicFeature`	Yes	Handles the italic text format
`UnderlineFeature`	Yes	Handles the underline text format
`StrikethroughFeature`	Yes	Handles the strikethrough text format
`SubscriptFeature`	Yes	Handles the subscript text format
`SuperscriptFeature`	Yes	Handles the superscript text format
`InlineCodeFeature`	Yes	Handles the inline-code text format
`ParagraphFeature`	Yes	Handles paragraphs. Since they are already a key feature of lexical itself, this Feature mainly handles the Slash and Add-Block menu entries for paragraphs
`HeadingFeature`	Yes	Adds Heading Nodes (by default, H1 - H6, but that can be customized)
`AlignFeature`	Yes	Allows you to align text left, centered and right
`IndentFeature`	Yes	Allows you to indent text with the tab key
`UnorderedListFeature`	Yes	Adds unordered lists (ul)
`OrderedListFeature`	Yes	Adds ordered lists (ol)
`ChecklistFeature`	Yes	Adds checklists
`LinkFeature`	Yes	Allows you to create internal and external links
`RelationshipFeature`	Yes	Allows you to create block-level (not inline) relationships to other documents
`BlockquoteFeature`	Yes	Allows you to create block-level quotes
`UploadFeature`	Yes	Allows you to create block-level upload nodes - this supports all kinds of uploads, not just images
`HorizontalRuleFeature`	Yes	Horizontal rules / separators. Basically displays an `<hr>` element
`InlineToolbarFeature`	Yes	The inline toolbar is the floating toolbar which appears when you select text. This toolbar only contains actions relevant for selected text
`FixedToolbarFeature`	No	This classic toolbar is pinned to the top and always visible. Both inline and fixed toolbars can be enabled at the same time.
`BlocksFeature`	No	Allows you to use Payload's Blocks Field directly inside your editor. In the feature props, you can specify the allowed blocks - just like in the Blocks field.
`TreeViewFeature`	No	Adds a debug box under the editor, which allows you to see the current editor state live, the dom, as well as time travel. Very useful for debugging
`EXPERIMENTAL_TableFeature`	No	Adds support for tables. This feature may be removed or receive breaking changes in the future - even within a stable lexical release, without needing a major release.
`EXPERIMENTAL_TextStateFeature`	No	Allows you to store key-value attributes within TextNodes and assign them inline styles.

Notice how even the toolbars are features? That's how extensible our lexical editor is - you could theoretically create your own toolbar if you wanted to!

Creating your own, custom Feature

You can find more information about creating your own feature in our building custom feature docs.

TypeScript

Every single piece of saved data is 100% fully typed within lexical. It provides a type for every single node, which can be imported from @payloadcms/richtext-lexical - each type is prefixed with Serialized, e.g., SerializedUploadNode.

To fully type the entire editor JSON, you can use our TypedEditorState helper type, which accepts a union of all possible node types as a generic. We don't provide a type that already contains all possible node types because they depend on which features you have enabled in your editor. Here is an example:

1import type {
SerializedAutoLinkNode,
SerializedBlockNode,
SerializedHorizontalRuleNode,
SerializedLinkNode,
SerializedListItemNode,
SerializedListNode,
SerializedParagraphNode,
SerializedQuoteNode,
SerializedRelationshipNode,
SerializedTextNode,
SerializedUploadNode,
TypedEditorState,
SerializedHeadingNode,
15} from '@payloadcms/richtext-lexical'
16
17const editorState: TypedEditorState<
| SerializedAutoLinkNode
| SerializedBlockNode
| SerializedHorizontalRuleNode
| SerializedLinkNode
| SerializedListItemNode
| SerializedListNode
| SerializedParagraphNode
| SerializedQuoteNode
| SerializedRelationshipNode
| SerializedTextNode
| SerializedUploadNode
| SerializedHeadingNode
30> = {
root: {
  type: 'root',
  direction: 'ltr',
  format: '',
  indent: 0,
  version: 1,
  children: [
    {
      children: [
        {
          detail: 0,
          format: 0,
          mode: 'normal',
          style: '',
          text: 'Some text. Every property here is fully-typed',
          type: 'text',
          version: 1,
        },
      ],
      direction: 'ltr',
      format: '',
      indent: 0,
      type: 'paragraph',
      textFormat: 0,
      version: 1,
    },
  ],
},
59}

Alternatively, you can use the DefaultTypedEditorState type, which includes all types for all nodes included in the defaultFeatures:

1import type { DefaultTypedEditorState } from '@payloadcms/richtext-lexical'
2
3const editorState: DefaultTypedEditorState = {
root: {
  type: 'root',
  direction: 'ltr',
  format: '',
  indent: 0,
  version: 1,
  children: [
    {
      children: [
        {
          detail: 0,
          format: 0,
          mode: 'normal',
          style: '',
          text: 'Some text. Every property here is fully-typed',
          type: 'text',
          version: 1,
        },
      ],
      direction: 'ltr',
      format: '',
      indent: 0,
      type: 'paragraph',
      textFormat: 0,
      version: 1,
    },
  ],
},
32}

Just like TypedEditorState, the DefaultTypedEditorState also accepts an optional node type union as a generic. Here, this would add the specified node types to the default ones. Example:

1DefaultTypedEditorState<SerializedBlockNode | YourCustomSerializedNode>

This is a type-safe representation of the editor state. If you look at the auto suggestions of a node's type property, you will see all the possible node types you can use.

Make sure to only use types exported from @payloadcms/richtext-lexical, not from the lexical core packages. We only have control over the types we export and can make sure they're correct, even though the lexical core may export types with identical names.

Automatic type generation

Lexical does not generate accurate type definitions for your richText fields for you yet - this will be improved in the future. Currently, it only outputs the rough shape of the editor JSON, which you can enhance using type assertions.

Admin customization

The Rich Text Field editor configuration has an admin property with the following options:

Property	Description
`placeholder`	Set this property to define a placeholder string for the field.
`hideGutter`	Set this property to `true` to hide this field's gutter within the Admin Panel.
`hideInsertParagraphAtEnd`	Set this property to `true` to hide the "+" button that appears at the end of the editor

Disable the gutter

You can disable the gutter (the vertical line padding between the editor and the left edge of the screen) by setting the hideGutter prop to true:

1{
name: 'richText',
type: 'richText',
editor: lexicalEditor({
  admin: {
    hideGutter: true
  },
}),
9}

Customize the placeholder

You can customize the placeholder (the text that appears in the editor when it's empty) by setting the placeholder prop:

1{
name: 'richText',
type: 'richText',
editor: lexicalEditor({
  admin: {
    placeholder: 'Type your content here...'
  },
}),
9}

Related Guides

How to render rich text from Payload in a Next.js frontend

See what others are building with Payload.

"Payload has transformed the way our clients manage content. It's an indispensable tool for any modern agency."

Deploy your entire stack in one place with Payload Cloud.

Microsoft chose Payload to tell the world about AI.