Who is using Plate in production?

[zbeyens]

Plate is being adopted by a lot of companies right now, we would love to list some of them on https://platejs.org

If you are using plate, and you don't mind sharing this fact with the world, please post your company name with a link in the comment below. We appreciate it a lot.

[dylans]

Living Spec

[rsbowers]

agnoStack

[hwildwood]

Process Street

P.S We're also hiring 🙂

[baptisteArno]

Typebot - Conversational forms builder

[cungminh2710]

Trip.Social - Travel Publishing Platform

[jeffsee55]

Tina.io is using this, we've built an MDX editor into our CMS!

[fridaystreet]

ALEiGN

[tjramage]

We recently revamped our entire editing experience in Avion. There's a lot of RTE libraries out there, but we ended up choosing Plate to use as our foundation:

Under the hood, we are storing everything in Markdown and converting to/from Slate syntax when editing/saving. We're pretty happy with the end result 😄

[rjlg]

We recently revamped our entire editing experience in Avion. There's a lot of RTE libraries out there, but we ended up choosing Plate to use as our foundation:

Under the hood, we are storing everything in Markdown and converting to/from Slate syntax when editing/saving. We're pretty happy with the end result 😄

Nice work @tjramage.

I am also looking to implement plate in a similar fashion. What method are using to convert to/from Slate syntax when editing/saving?

[tjramage]

Good question @rjlg. That was definitely one of the trickier parts for us. In a nutshell:

• When saving, we serialize Plate/Slate --> HTML, and then convert HTML --> Markdown. I know that sounds wasteful on the face of it, but this was the easiest and most robust option for us (plus there are some really mature HTML / Markdown conversion libraries out there).

• When loading the editor, we convert Markdown --> HTML, and then feed that to our instance of Plate (which already has HTML deserialization support).

Worth noting that we hit roadblocks with the HTML serializer within Plate. So we ended up forking the code to add proper support for encoded entities and URI encoding within content (and a few other tweaks). I'm planning on contributing these enhancements back into the Plate repo at some point soon...

Good luck! 👍

[sheharyarIshfaq]

@tjramage Thanks for your insights!

I took your advice and explored a few Markdown ↔ HTML conversion libraries, but I ran into the same issue—styles, especially for tables and other structured elements, don’t persist well during the conversion process.

Right now, I get Markdown from AI, deserialize it into Plate.js nodes, and display it in the editor. However, when users edit the content, it gets converted back to Markdown for storage, which results in significant style loss. I also considered storing Markdown in the database and converting it to HTML before displaying it, but that hasn’t worked well either.

Given these challenges, I’m considering storing the content as raw HTML in the database and deserializing it into Plate.js nodes when needed. This seems like a more reliable approach, especially since I also have an "Export to DOCX" feature, which might work better with HTML.

I’ve also seen some people mention storing Plate.js nodes directly, but I feel that might not be as flexible. Would love to hear your thoughts—do you think storing raw HTML is a practical long-term approach?

Appreciate your time!

[tjramage]

@sheharyarIshfaq Hmmm, weird. Our Markdown formatting persists cleanly between MD and HTML. For example, below is a table with formatted table headers, as we store it in the database:

| ***Table Header 1*** | `Table Header 2` |
| --- | --- |
| Content | Content |

Table header 1 is both bold and italic (we store this as a triple asterisk) and table header 2 is in code formatting.

If you are considering storing raw HTML, I think I would just go straight to storing the Plate JSON instead. The only reason we use Markdown is because we integrate with lots of platforms, and some of these integrations are 7+ years old at this point. If you don't have these issues, then I'd just store Plate straight to the database.

Things you should probably consider:

1. How will your Plate/Slate syntax change over time? It's possible you will need to upgrade a custom plugin which requires a syntax change in the Plate structure – this will cause issues with older content in your database.
2. If you may leave Plate/Slate in the future for another editor, you'll need to perform a migration.
3. Will you offer search features? Storing serialised JSON or HTML both come with additional problems when it comes to indexing and tokenising.

That said, storing MD is also not great, due to its fairly strict styling options (no underline, highlight, etc). We have had to build our own custom "flavour" of Markdown to provide better support for non-MD features (e.g. line-breaks inside of tables).

Sorry I can't give you a definitive answer – sadly, it's not an easy choice...

[sheharyarIshfaq]

@tjramage Thanks for the detailed response—I really appreciate it!

That makes a lot of sense, especially the points about long-term compatibility and potential migration challenges. I’ll take a deeper look into these considerations and discuss them with my team before finalizing our approach.

If I run into any further questions, I’ll definitely reach out. Once again thanks :)

[tjramage]

No problem. Good luck!

[ZhangMingZhao1]

@tjramage Thanks for your insights!感谢您的见解！

I took your advice and explored a few Markdown ↔ HTML conversion libraries, but I ran into the same issue—styles, especially for tables and other structured elements, don’t persist well during the conversion process.我听取了你的建议并探索了一些 Markdown ↔ HTML 转换库，但遇到了同样的问题——样式，尤其是表格和其他结构化元素的样式，在转换过程中不能很好地保留。

Right now, I get Markdown from AI, deserialize it into Plate.js nodes, and display it in the editor. However, when users edit the content, it gets converted back to Markdown for storage, which results in significant style loss. I also considered storing Markdown in the database and converting it to HTML before displaying it, but that hasn’t worked well either.目前，我从 AI 获取 Markdown，将其反序列化为 Plate.js 节点，并在编辑器中显示。但是，当用户编辑内容时，它会被转换回 Markdown 进行存储，这会导致严重的样式损失。我也考虑过将 Markdown 存储在数据库中，然后在显示之前将其转换为 HTML，但效果也不好。

Given these challenges, I’m considering storing the content as raw HTML in the database and deserializing it into Plate.js nodes when needed. This seems like a more reliable approach, especially since I also have an "Export to DOCX" feature, which might work better with HTML.考虑到这些挑战，我正在考虑将内容以原始 HTML 格式存储在数据库中，并在需要时将其反序列化为 Plate.js 节点。这似乎是一种更可靠的方法，尤其是因为我还有一个“导出为 DOCX”功能，它可能更适合 HTML 格式。

I’ve also seen some people mention storing Plate.js nodes directly, but I feel that might not be as flexible. Would love to hear your thoughts—do you think storing raw HTML is a practical long-term approach?我也看到有人提到直接存储 Plate.js 节点，但我觉得这可能不太灵活。想听听您的想法——您认为存储原始 HTML 是一个切实可行的长期方案吗？

Appreciate your time!  感谢您的时间！

In fact, you can html data and json data are stored, html data for read-only state rendering, editing state or use slate json data, json data can be stored in the html data on the outermost container of a key attribute, will be the whole html as a string in the database. This can solve the problem that read-only state does not need to introduce an editor to render faster, and edit state does not lose style.

[neko-neko]

We using Plate! Resily - OKR SaaS

[rjlg]

Good question @rjlg. That was definitely one of the trickier parts for us. In a nutshell:

• When saving, we serialize Plate/Slate --> HTML, and then convert HTML --> Markdown. I know that sounds wasteful on the face of it, but this was the easiest and most robust option for us (plus there are some really mature HTML / Markdown conversion libraries out there).
• When loading the editor, we convert Markdown --> HTML, and then feed that to our instance of Plate (which already has HTML deserialization support).

Worth noting that we hit roadblocks with the HTML serializer within Plate. So we ended up forking the code to add proper support for encoded entities and URI encoding within content (and a few other tweaks). I'm planning on contributing these enhancements back into the Plate repo at some point soon...

Good luck! 👍

Thanks @tjramage!

Look forward to seeing your enhancements.

[JannesMeyer]

airfocus

[guldenmw]

Buffer

[linonetwo]

Tiddlywiki：Main framework https://github.com/Jermolene/TiddlyWiki5

Use plate in a plugin: https://github.com/tiddly-gittly/slate-write
Demo: https://tiddly-gittly.github.io/slate-write/

[AlekseyManetov]

We're using plate for our own open-sourced full-featured Rich Text Editor as a part of UUI library.
Demo - https://uui.epam.com/demo?id=RTE
Docs - https://uui.epam.com/documents?id=richTextEditor&mode=doc&skin=UUI4_promo&category=components
Source - https://github.com/epam/UUI/tree/main/uui-editor

[DineshCodeFlow]

We, Shorter Loop is using Plate js.

[varun508]

@DineshCodeFlow
how do you save that in the database? I mean do you store the original plate json, markdown, or the html.

[kyledickey]

Just started using it for Diary - GitHub <3

[sewellstephens]

Currently using it for Krastie AI

[caoxing9]

teable

[kualta]

fountain.ink

[golanglemonade]

theopenlane.io - Open source project as well: github.com/theopenlane

[sshuvoo]

A powerful git based CMS https://sitepins.com/