How to create a simple HTML markup field with a WYSIWYG editor?

[MurzNN]

I need to create an HTML markup field with a WYSIWYG editor that will be stored in the database as an HTML string. Plan to use there only simple markup like <p>, <b>, <i>, <a> and that's all.

I see that Payload provides the Rich Text Field field type, but it stores in the database not HTML, but an object.

So, is there any option or workaround to make this field store in the database the HTML code instead of the object, like a classic WYSIWYG editor like CKEditor or TinyMCE?

Or, maybe, use CKEditor or TinyMCE directly?

[sueun-dev]

fwiw, I don't think the built-in Lexical richText field can be turned into a “store HTML as the field value” editor. The actual richText value is still Lexical JSON.

The closest built-in helper is lexicalHTMLField():

fields: [
  {
    name: 'content',
    type: 'richText',
    editor: lexicalEditor(),
  },
  lexicalHTMLField({
    lexicalFieldName: 'content',
    htmlFieldName: 'content_html',
  }),
]

I tried this on @payloadcms/richtext-lexical@3.84.1 with SQLite. The API response got content_html, but the DB column stayed null when I only submitted the richText field.

Small gotcha: storeInDB: true doesn't auto-save the converted HTML either. It just stops Payload from deleting an incoming content_html value before save. So if HTML needs to be the canonical stored value, I'd use a custom field/admin component with TinyMCE/CKEditor, or add your own write hook that converts Lexical JSON to HTML before save. If you only need HTML for rendering/API output, lexicalHTMLField() or convertLexicalToHTML is the path.

[MurzNN]

Yes, seems a custom beforeSave hook can be a solution, here is how we can convert the Lexical object to the HTML string:

import { convertLexicalToHTML } from '@payloadcms/richtext-lexical/html'
...
  const htmlString = convertLexicalToHTML({ data: value })

But the issue is the editing already saved data: we need to convert it back to the Lexical object on read, so in result will receive the same issue - object as the field value in API responses ;)

[MurzNN]

Seems this can be fixed from the Payload side by providing an option, instead of such workarounds, so created a feature request: #16732 - like, repost, share! ;)

[sueun-dev]

Sorry, my storeInDB note was wrong about the result. I ran it on Payload 3.84.1 with SQLite through the Local API. With the default, the content_html column stays NULL. With storeInDB: true it's NULL after create, and after each content-only update it holds the previous revision's HTML (saving Bravo stored Alpha's HTML). The API returned HTML for the current content at every step. The cause appears to be updates backfilling omitted fields from the original doc, which afterRead has already filled (getFallbackValue.ts). So for HTML that's current in the DB, your own beforeChange hook or the textarea + custom editor route is still the way.

[yudin-s]

Short answer: if you need the canonical stored value to be HTML, use a custom textarea/editor field and treat Lexical as optional.

richText in Payload is Lexical JSON by design, so the robust patterns are:

1. Lexical as source of truth + generated HTML field

   • keep content as richText
   • generate content_html in a hook on create/update

2. HTML as source of truth

   • use a plain text/textarea field (or custom admin component with TinyMCE/CKEditor)
   • sanitize allowlist tags (p,b,i,a) on save before persisting

A minimal hook approach for pattern #1 is usually the least invasive migration path. If you need, I can share a concrete beforeChange hook example that writes sanitized HTML to a second field.

If this solved it, please mark the answer so others can find it faster.

[MurzNN]

Thank you for the details, option 2 "HTML as source of truth" looks more promising and simple, so seems this can be resolved via a custom React widget for the text field?

[yudin-s]

Yes. If HTML is the source of truth, I would make it a normal string field in Payload and only replace the admin UI with a custom React field/editor.

The important bit is that the saved field value stays an HTML string:

{
  name: 'content_html',
  type: 'textarea',
  admin: {
    components: {
      Field: '@/fields/HtmlEditorField',
    },
  },
}

Then the custom field component can render TinyMCE/CKEditor/etc. and call the Payload field setter with the editor HTML. Add server-side sanitizing in a hook before saving, because admin UI filtering alone is not enough.

With that shape, the API response is already HTML and you do not need to convert HTML back into Lexical JSON. Only choose Lexical if you want Lexical JSON to remain the canonical stored value.

[Eugene-Stone]

If you still need this, I’ve built Payload HTML Editor, a Tiptap-powered WYSIWYG field for Payload CMS 3. It stores the editor content as an HTML string in a regular Payload textarea field rather than as Lexical JSON.

It supports formatting, links, and optional features such as images, tables, and HTML source editing. You can find installation instructions and examples in the README, or install it from npm.

Tiptap parses HTML through an editor schema, so it may normalize equivalent tags (for example, b to strong). If you need to preserve the exact markup, please test it with your content first. I’d be glad to hear whether it fits your use case.