I still remember the first time I looked into RTEs — confident, curious, and completely unaware of the rabbit hole I was about to fall into.

In my head, an RTE was just a fancy textbox with a toolbar. Maybe a text area with bold, italics and the occasional list. Nothing more.
But the moment I actually started working on one, that myth busted really quickly.

It’s a good reminder of something we, as engineers, often forget — we’re always beginners at something new.

I’m writing this blog to summarize my learnings so far. Hopefully, it helps someone looking to work on RTEs to get a gist of what an RTE really is and the challenges that come with it.

Oh, and by the way: RTE stands for Rich Text Editor, which can represent data in HTML, JSON or other formats, depending on how you want to play with your data.

Building an RTE isn’t just a task; it’s a journey.

How is working with an RTE different from an input field?

How is the data managed?

In a multiline textbox, data is usually just a string.
But when building a custom RTE, we need to decide how the data will look, be stored and served to the user.
We need to think about all possible combinations users might create.
And we need to handle the CSS that might come along with that data — quite possible, right? After all, we’re giving them formatting options.

A simple example:

<h2 style="text-align: center;"><strong>Hi there!</strong></h2>

So right from storing data, preserving spaces, saving CSS, and handling attributes — it’s all on us.

Wondering how the JSON for the above might look? Here it is:

{
"type": "doc",
"uid": "34d5dc2f6a55495d8aebf38a1ea72033",
"attrs": {},
"children": [
{
"type": "h2",
"attrs": {
"style": {
"text-align": "center"
},
"redactor-attributes": {
"style": "text-align: center;"
}
},
"uid": "d81a4b5214fc48f5b3181c00c27fe338",
"children": [
{
"text": "Hi there!",
"attrs": {
"style": {}
},
"bold": true
}
]
}
]
}

The above JSON, is just for one html line of code, can you imagine what it would look like for the actual real world data?🤔

Ohh and yes, this is the same data we might need to look into in case of failure/errors.

Interestingly complex elements

In an RTE, two elements that really make things interesting are images and tables.

They’re total game changers for content writers, making the content look rich, structured and honestly, just better.

But behind all that good-looking stuff is where the real engineering challenge lies — how efficiently you handle their data.

Images

Images aren’t just simple blocks dropped into text.

There’s so much that goes behind the scenes!

You need to keep track of how they’re resized, how they’re aligned, their captions, alt text and even whether they’re inline or block-level.

So every time a user drags that little resize handle or centers the image, your RTE has to capture, update, and store all of it perfectly.

Tables

Tables take things up another notch.

Each cell can have completely different content — a paragraph, an image, a list, maybe even a nested table (because why not?).

And every action inside that table, from merging cells to moving the cursor between them, needs to be handled gracefully without breaking the structure.

It’s these “small” things that really separate a basic RTE from a great one.

HTML standards and protocols

When dealing with RTE data, we also need to ensure that it complies with HTML standards and protocols — invalid markup can easily creep in, and browsers don’t always interpret it the same way.

Consider this example:

<p>
<h4>Hi</h4>
<a href="/link">Link here</a>
<p>Bye</p>
</p>

What do you think? Is the HTML above valid?

Yes? No? Skeptical?

In either case, how would you:

Store this data?
Manage invalid inputs?

Keeping your RTE aligned with web standards helps maintain predictable rendering and prevents broken layouts or corrupted content structures.

Complex selection logic

Take the snippet above — it contains multiple paragraphs, an anchor link and text selections spread across elements.

Now, what happens if the user applies another formatting option, like italics, to that selection?

We need to ensure that our JSON structure (in case of a JSON-based RTE) accounts for such scenarios and handles them gracefully.

Custom behaviors for elements

One of the most common examples here is the Tab key.

In paragraphs → it indents text
In tables → it moves selection to the next cell
In lists → it creates a sublist (nesting)

And we need to handle all of these cases — and many more.

Real-world problems

Copy–Paste

Ah yes, the engineer’s favorite —- copy code from Stack Overflow or ChatGPT and paste!

In this case, our RTE should be able to:

Interpret the source of the copied content
Detect anomalies in the snippet
Fix them and display the result correctly

Undo–Redo

How can any RTE not support the most basic operation of all? (And yet, it’s not as simple to implement as you’d think!)

Performance

With all the heavy HTML, frequent formatting and rendering, we must ensure:

Minimal re-renders
Quick formatting operations
No visible lag for the user

Enhancements appreciated

Drag and drop (DnD)

Imagine having loads of data and not being able to drag and drop when needed. What a nightmare!

We must ensure that when the DnD operation completes, the correct JSON/HTML structure is formed — else the entire data could get corrupted.

Floating toolbars

A simple yet powerful enhancement — when a user selects text, show a relevant toolbar with actions they can perform.

It makes a content writer’s life so much easier.

💡 Pro tip

Remember: The data entered in your RTE might not be used immediately. It can also be manipulated downstream by the user or other systems.

So make sure that any changes you make to your code don’t unintentionally break someone’s CSS or structure.

💬 Fun fact:

By now, you might have guessed — this very blog was drafted on an RTE! 😄

Google Docs? Confluence? Custom built?

Final Takeaway

RTEs are deceptively tricky, part text field, part layout engine, part magician. But once you understand their quirks, they become surprisingly fun to work with.

So read the docs, keep a sandbox ready, and learn from other editors. And most importantly, don’t let that innocent-looking toolbar fool you again.😀

Shreya Kamble is a Software Engineer II at Contentstack. Follow her on LinkedIn here.

Shreya Kamble

Other posts by author

Ready to reimagine possible?