[Rich Text Field] Option to store HTML string in the database instead of Lexical object

[MurzNN]

Payload has a Rich Text Field field type that provides a full-featured WYSIWYG editor.

But the issue is that it stores a Lexical object in the database, not the HTML string. This makes it hard to render the value from the API calls, because we should use a specific library to convert the Lexical object to HTML.

It is easy when we use the same stack (JS, React), but it becomes a challenge if we use another language or stack that renders the API response!

So, please provide an option in the Rich Text Field to store the value as an HTML string in the database - this will make the API response more friendly for different apps.

Alternatively, maybe just provide a separate field type "Formatted text" with a classic WYSIWYG like CKEditor, or TinyMCE?

[MurzNN]

Also, taking into account the AI era, maybe also worth adding an option to store the content in the Markdown format ;)

[AlessioGr]

We could expose additional converters for a variety of different frontend frameworks in the future, like svelte. We'll likely never store the editor content as html though, or switch to an editor framework that stores it as such. Json is much more flexible, as it allows us to easily iterate through it. This makes it easy to build converters for a variety of different shapes (jsx, html, markdown, plaintext ...). LLMs should also be able to easily one-shot building a converter from the JSON => any other output format. It also allows us to support features like hooks, relationships and localization within nested lexical fields.
If we stored it as html, well you'd be stuck with html, and building a converter into different formats gets much more complex.

Storing the content as html would mean we'd have to convert it to JSON and back every single time you read the document. You can store it in the db using a separate field + beforeChange hook, but we don't recommend it. It leaves you with stale data, as content can change in between saves (e.g. through relationships that require population), wastes resources as you're now storing the same data twice, and bloats the responses.

Why not use our html converters, and convert it on-demand, or via a virtual lexicalHTMLField?

[MurzNN]

Thank you for the details! In my case, I just have a lot of text fields, where should provide a "limited rich text" editing experience - marking some parts of text as bold, italic, underline, creating paragraphs using <p> tag, and allowing to make links using <a> tags, and that's all.

So, there is no complex markup expected, but one document has 10+ such fields.

Yes, with a virtual lexicalHTMLField it will work, but will require running the HTML converter each time when the document is read. So, if we read 100 documents, the HTML conversion will run 1000 times, decreasing the performance.

A workaround with a separate field + beforeChange hook looks better from the performance point of view, but will require creating 10+ new real fields and storing duplicates in the database.

So, seems the best workaround for my case - is to use just a textarea field and attach the Lexical editor to it manually.

Why not CKEditor or TinyMCE - because we already use Lexical for more complex fields, and do not want to provide different editor for such fields.

[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.