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! 👍

[tjramage]

There are many robust MD <--> HTML conversion libraries out there. If your project isn't too constrained, I would recommend you build on top of one of these rather than from the ground up.

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

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

[enzostvs]

MEE6

[bjarkih]

We're very happy Plate users at https://dropdeck.com, designing slides based on text input. Happy for you to add our name and logo on your list! 😃

[bjarkih]

P.S. We've rebranded to Typeset - https://typeset.com - please update our name and logo when you get a chance :)

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

[dickeyy]

Just started using it for Diary - GitHub <3

[sewellstephens]

Currently using it for Krastie AI

[caoxing9]

teable

[kualta]

fountain.ink