Since the Umbraco 16 release, Umbraco ships only with the TipTap Rich Text Editor. This was unfortunately something that Umbraco was forced to do. TinyMce 7 has a license that is incompatible with the open source license of Umbraco and TinyMce 6 was going out of support. So an alternative had to be found.

Umbraco did a pretty good job at abstracting the rich text data. In Umbraco 15 both TinyMCE and TipTap were still present and exchangeable because of this abstraction. And arguably, the way you can set up your toolbars for the TipTap editor is superior to TinyMCE. But still, a new Rich Text Editor is a big change that presents real challenges.

These challenges are most obvious when looking at the Umbraco forum's tip-tap tag. Topics vary, but a few come up again and again:

• Additional HTML tags getting added to the markup, like a <p> tag inside a <li>
• The inability to add certain tags to TipTap, like <script> tags
• The inability to add styling to an element, for instance to create a link that looks like a button

These are valid challenges, especially if you're upgrading from an existing TinyMCE setup. But this is also a good moment to ask two questions:

• Why do I want the same behaviour?
• And was the old behaviour actually any good to begin with?

You don't have to migrate everything at once

Before getting into that, it's worth knowing that TinyMCE is still available as a community package for Umbraco 16+. If you're in the middle of a project, dealing with a large codebase, or just not ready to rethink your Rich Text Editor setup right now, that's a valid escape hatch. Swap in the package, keep things running, and give yourself time to migrate properly.

But "later" should still be on the roadmap. The package is community maintained, not an official Umbraco product, so there are no guarantees around long-term support or compatibility with future Umbraco versions. Relying on it indefinitely carries the same risk as the situation Umbraco just came out of with TinyMCE 6.

So use it if you need to. Just don't treat it as a permanent solution.

The RTE is not a page builder

I'm not a big fan of giving editors too much freedom in a Rich Text Editor. Don't get me wrong, RTEs are great and help editors a lot. But give too much rope and things go wrong fast. My preference is for RTEs to handle the basics: adding a link, making text bold or italic, maybe a table if the frontend deals with it gracefully on mobile.

What I don't like is image placement and scaling inside an RTE. Without proper processing this is a problem for performance and mobile layouts. I also don't like HTML snippets or trying to add CSS classes to elements from within an editor. It's error prone, and if something breaks, you need HTML knowledge to fix it. That's not a realistic expectation for most editors.

So when people ask how to replicate that kind of behaviour in TipTap, I'd rather ask why they need it at all.

Stop fighting the editor, start working with Umbraco

Instead of trying to make TipTap behave like TinyMCE did, consider using the tools Umbraco already gives you.

Need a link that looks like a button? Use a block inside the Rich Text Editor. TipTap has solid block support, and Umbraco exposes this well. You get a structured piece of content with its own view, its own properties, fully typed, fully renderable. An editor picks a "Button" block, fills in the label and the link and that's it. No CSS classes, no raw HTML, no risk of someone pasting style="color:red" into a script tag three months later.

Need a pull quote, a callout, a code snippet with syntax highlighting? Same answer. Model it as a block. Render it properly. Keep the RTE itself lean.

The argument I keep hearing is that recreating all of this takes more time than just making the old thing work again. That's sometimes true in the short term. But you're building something more maintainable, more predictable and more editor-friendly.

There's another reason to think twice before pouring effort into recreating editor-specific behaviour: Umbraco has already switched its default Rich Text Editor once. It could happen again. If your implementation leans heavily on workarounds and editor-specific quirks, you're setting yourself up for the same migration pain all over again. If instead your RTE is kept lean and the complex bits live in blocks with their own models and views, a future editor switch becomes much less of an event. The RTE just renders text. Everything interesting is already abstracted away.

What about the extra markup?

The <p> inside <li> is worth addressing separately, because it looks like a bug but it isn't. TipTap is built on ProseMirror, which uses a strict document schema where every node needs to contain the right type of child node. For list items, that child is a block node and a paragraph is that block node. This is what makes editing reliable: without it, you can end up in situations where the cursor can't be placed inside a list item at all, or where deleting an item breaks unexpectedly.

This behaviour is not unique to TipTap. Any editor built on ProseMirror does the same thing, and that includes quite a few well-known ones. TinyMCE handled lists differently, but that doesn't make TinyMCE's approach the correct one.

If your frontend CSS breaks because of this, that's a one-time fix, typically just adjusting margin or display rules on li p. Once it's done, you're working with markup that is actually more structurally consistent than what TinyMCE produced.

Closing thought

A new editor is disruptive. But disruption is also a chance to reconsider decisions that were made years ago under different constraints, maybe with less knowledge of what Umbraco could do, or just because TinyMCE made it easy and easy felt like good enough.

TipTap is not TinyMCE. It's not trying to be. And once you stop expecting it to be, you might find it pushes you toward solutions that are cleaner, better structured and easier to hand off to an editor who has no idea what a DOM is.

Work with the grain of the tool, not against it.