Why I Built Yet Another Rich Text Editor

CyteEditor — Tue, 18 Aug 2026 10:04:13 +0000

Every few years, a new rich text editor appears and promises to be "the last one you'll ever need." And yet, here I am, building another one.

Let me explain why.

The Paste Problem That Remained Unsolved

I was building a document management platform. Users would create reports in Microsoft Word — complete with tables, charts, headers, and complex formatting — then paste them into our web editor.

The result? Disaster. Every time.

We tried every major editor on the market. They're all excellent products, but they share the same weakness: paste handling is an afterthought.

When a user copies from Word, the clipboard doesn't contain clean HTML. It contains Microsoft's proprietary markup:

<!-- What Word puts in your clipboard -->
<p class="MsoNormal" style="margin:0cm;margin-bottom:.0001pt">
  <span style="font-size:12.0pt;font-family:'Times New Roman',serif;
    mso-fareast-font-family:'Times New Roman';mso-ansi-language:EN-US;
    mso-fareast-language:ZH-CN;mso-bidi-language:AR-SA">
    Hello World
  </span>
</p>

Standard HTML parsers either strip all the styling (losing formatting) or pass it through as-is (resulting in broken rendering). Neither approach works.

The Reverse Engineering Journey

I spent weeks reverse-engineering how Office applications encode content in clipboard HTML. Here's what I found:

Word uses mso-* CSS properties and conditional comments (<!--[if gte mso 9]>) to encode document structure. Tables are wrapped in VML fallbacks. List numbering uses proprietary mso-list properties.

Excel encodes cells as HTML tables with mso-* properties for cell merges, formulas, and number formats.

WPS (popular in Asia) uses a slightly different variant of Microsoft's markup, with its own set of proprietary properties.

Google Docs uses a cleaner HTML structure but with nested <b style="font-weight:normal"> patterns that confuse standard parsers.

Each source requires different parsing rules. A one-size-fits-all HTML sanitizer simply cannot handle this.

Building CyteEditor

The result is a dedicated paste parser engine — approximately 2,300 lines of code that:

Detects the source application by analyzing clipboard metadata and HTML patterns
Applies source-specific rules for Word, Excel, WPS, and Google Docs
Reconstructs semantic structure — converting Microsoft markup into clean, semantic HTML while preserving visual fidelity

But I didn't stop at paste. While building the editor, I addressed other pain points:

Framework fragmentation: Most editors support 1-2 frameworks officially. CyteEditor ships 6 official adapters (Vue 3, Vue 2, React, Svelte, Angular, Vanilla JS).
Build tool dependency: Modern editors require a bundler. CyteEditor ships both ESM (for modern builds) and IIFE (for <script> tag inclusion).
No version history: Other editors leave version management entirely to the application layer. CyteEditor offers a built-in snapshot system (4 auto-triggers: blur/paste/import/interval) and rich-text version compare with block-level Diff and scroll-synced dual-pane view. No major rich text editor ships this built-in.
Subscription fatigue: Most commercial editors moved to subscription-only pricing. CyteEditor offers a perpetual (one-time purchase) option alongside subscriptions.

The Result

CyteEditor is a full-featured, full-framework rich text editor SDK with the most sophisticated paste fidelity I've built — and one of the few editors with built-in snapshot & version compare.

The free Community tier includes the core editor and all 6 framework adapters. Pro extensions (advanced paste, docx export, version compare) require a commercial license — with a perpetual option.

Try it: www.cyteeditor.com/playground — paste a complex Word document and see for yourself.

What's Next

I'm actively working on:

Improved table editing (drag-to-resize, keyboard shortcuts)
Markdown shortcuts (type # for heading, - for list)
Plugin extension API for custom toolbar buttons