Hi Renato,

Thank you for reporting this behavior.

The TextChanged event of RadEditor relies on a server-side string comparison between the posted content and the previous ViewState value. Due to the nature of rich-text editing — where the browser's contentEditable normalizes the DOM, and RadEditor's content filters transform the HTML on every round-trip — the posted value can end up identical to the ViewState value even when the user has made visible changes. This makes the TextChanged event unreliable for consistent change detection in RadEditor.

We have published a Knowledge Base article that explains the root cause in detail and provides two proven approaches to detect content changes reliably:

TextChanged Event of RadEditor Does Not Fire

Approach 1 — Track Changes (Recommended): Enable the built-in Track Changes feature (EnableTrackChanges="true"), which monitors actual DOM mutations and embeds semantic markers. This is the most reliable method as it tracks insertions, deletions, and formatting changes at the DOM level rather than relying on string comparison.

Approach 2 — Client-Side Content Comparison: Use the OnClientLoad and OnClientSubmit events to capture and compare get_html(true) at two consistent points. This ensures both values pass through the same filter pipeline, eliminating false negatives from content normalization.

I have attached two ready-to-run test pages (TrackChangesApproach.aspx and ClientSideWorkaround.aspx) that demonstrate both approaches side-by-side. Each page also shows whether the native TextChanged event fired, so you can directly observe the difference.

Important note: Do not use get_initialContent() for comparison — it stores the raw pre-filter HTML, which will always differ from get_html(true) even without user edits.

Regards,
Rumen
Progress Telerik