What Are Track Changes? 2026 Developer Guide for Web Editors

TLDR

Track changes is a document editing feature that records insertions, deletions, and formatting modifications as reviewable proposals rather than direct overwrites. Most developers know the concept from Microsoft Word or Google Docs, but the real challenge starts when you need to implement it in a web-based editor like TinyMCE, Froala, or CKEditor 4. These editors don’t ship with native track changes support. You either build a custom solution on top of the editor’s DOM manipulation layer (expect months of work) or integrate a purpose-built plugin. This guide covers the underlying data model, how tracking works at the markup level, what to evaluate in third-party plugins, and practical integration considerations for teams building collaborative editing into SaaS or enterprise applications.

What Are Track Changes?

At its simplest, track changes is a feature that records proposed modifications to content and lets a second party accept or reject each one. The interaction model has three parts: an author makes edits, those edits are stored as discrete operations with metadata (who, when, what type), and a reviewer processes each operation by accepting or rejecting it.

In desktop applications, this is a solved problem. Word has had it for decades. Google Docs calls it Suggesting Mode. But for developers building browser-based applications on top of rich text editors, track changes is anything but solved. TinyMCE, Froala, and CKEditor 4 provide excellent core editing, but none of them include native track changes in their standard distributions.

This gap is well-documented. Practitioners on Reddit’s r/AskProgramming have discussed it extensively: developers building collaborative editing tools quickly discover that base editors lack the track changes feature their users expect. Conversations often start with plain-text diff approaches as a workaround, but real track changes requires richer integration that preserves formatting context and supports the full accept/reject workflow.

Plugins like those from Loop Index fill this gap for TinyMCE, Froala, and CKEditor 4. CKEditor 5 offers its own premium plugin. The point is that track changes in web editors requires deliberate integration work, and understanding the underlying mechanics helps you make better build-vs-buy decisions.

How Track Changes Works Under the Hood

If you’ve only seen track changes from an end-user perspective (colored underlines, strikethroughs, accept/reject buttons), it’s worth understanding the mechanics that a developer needs to care about.

The Data Model

Every track changes implementation, whether in Word or a browser plugin, revolves around the same core data structure: a change operation. Each operation typically contains:

• Operation type: insert, delete, or format change
• Content affected: the text or node being modified
• Position data: where in the document the change occurs (character offset, DOM range, or node reference depending on the editor’s internal model)
• Author metadata: user ID, display name, color assignment
• Timestamp: when the operation was recorded
• Status: pending, accepted, or rejected

In a web-based editor, these operations map to the editor’s internal content model. TinyMCE, for example, operates on an HTML DOM. Track changes in TinyMCE means wrapping inserted text in marked-up spans (typically with custom attributes or classes encoding the operation metadata) and rendering deleted text with strikethrough styling rather than actually removing it from the DOM.

This is where complexity creeps in. The editor’s content model, its undo/redo stack, its paste handling, its serialization to HTML or JSON, all of these interact with the tracking layer. A naive implementation that simply wraps text in <ins> and <del> tags will break the moment a user pastes rich content, drags a block, or triggers an undo across a tracked boundary.

The Accept/Reject Workflow

When a reviewer accepts a change:

• For insertions: the tracking markup (span wrappers, metadata attributes) is stripped, leaving the inserted content as permanent document content.
• For deletions: the deleted content is removed from the DOM entirely, along with its tracking markup.
• For format changes: the new formatting becomes permanent and the tracking metadata is removed.

Rejection is the inverse. Accepting an insertion and rejecting a deletion both result in the content persisting. The difference is which operation’s metadata gets cleaned up.

This sounds straightforward until you consider overlapping changes from multiple authors, nested formatting operations, or changes that span block boundaries (like a deletion that crosses paragraph tags). These edge cases are where custom implementations tend to break and where mature plugins earn their value.

Display Modes

Word popularized four display modes that have become a conceptual standard:

• All Markup: every insertion, deletion, and formatting change visible with full color-coding
• Simple Markup: clean text with margin indicators showing where changes exist
• No Markup: hides visual indicators while keeping tracking data intact in the model
• Original: renders the document as if no changes were made

For web implementations, supporting multiple display modes means your tracking layer needs to separate the change data from its visual presentation. The underlying operations stay in the DOM (or a parallel data structure), but CSS classes or attribute toggles control visibility. This separation is important for both UX and for serialization. When you save the document, you need to preserve pending changes in the stored HTML or data model.

Why Web-Based Editors Don’t Include Track Changes Natively

This is a question every PM asks during evaluation. If track changes is such a common requirement, why don’t TinyMCE, Froala, and CKEditor 4 just include it?

The answer is architectural scope. These editors are designed as general-purpose rich text editing components. Their core responsibility is content creation: text input, formatting, media embedding, table editing, and HTML serialization. Track changes is a collaboration layer that sits on top of all of that, intercepting every content mutation and wrapping it in metadata.

Building track changes properly means hooking into the editor’s mutation observers or change events, handling every content operation type (not just text typing, but paste, drag-drop, find-replace, table operations, list manipulation), managing multi-author attribution, and providing a review UI. That’s essentially a second product built on top of the first.

A Stack Overflow thread on implementing track changes in a rich text editor reveals that even commercial editor vendors don’t always support the feature in their web offerings, noting it “is not yet available in the ASP.NET Rich Edit version (exists in the WinForms and WPF only).” Developers on Reddit report similar frustrations when they discover the editor they’ve already integrated lacks the collaboration features their end users demand.

Evaluating Track Changes Solutions for Your Editor

If you’re a developer or PM deciding how to bring track changes into your web application, there are three paths.

Option 1: Build It Yourself

This is tempting for teams with strong frontend engineering. The idea is to intercept the editor’s content change events and manage your own operation log.

What you’d need to build:

• Mutation interception for all content operations (typing, paste, drag, undo/redo, formatting commands)
• Inline markup rendering (insertion highlights, deletion strikethroughs, format change indicators)
• Author attribution with color assignment and metadata
• An accept/reject UI with per-change and batch operations
• Serialization logic that preserves pending changes across save/load cycles
• Conflict resolution for overlapping changes from multiple authors

Realistic timeline for a solid implementation: 3 to 6 months of dedicated frontend work, plus ongoing maintenance as the base editor releases updates that may break your hooks. Most teams that start down this path underestimate the edge cases, particularly around paste handling, undo/redo interaction, and nested formatting.

Option 2: Use a Purpose-Built Plugin

Plugins from providers like Loop Index bring track changes to TinyMCE, Froala, and CKEditor 4 without the build-from-scratch burden. CKEditor 5 has its own premium track changes plugin.

What to evaluate in a plugin:

• Operation coverage: Does it track insertions, deletions, and formatting changes? What about table operations, list manipulation, and media embeds?
• Multi-author support: Does it assign unique colors and metadata per author? How does it handle author identification (user ID passthrough, display name configuration)?
• API surface: Can you programmatically accept/reject changes? Query pending operations? Subscribe to change events for server-side persistence?
• Serialization: How are pending changes stored? Inline in the HTML (via data attributes or custom elements), or in a separate data structure? This affects how you persist and retrieve documents.
• Display modes: Can you toggle between showing all markup, simple indicators, or a clean view?
• Editor version compatibility: Plugin APIs can break across editor major versions. Confirm compatibility with your specific editor version.
• Performance at scale: How does the plugin perform with hundreds of pending changes in a single document? This matters for long-form content workflows.

Loop Index’s plugins support all three major editors with a rich API for customization. Check pricing and plans to see what fits your team’s scale (plans are based on monthly active users, starting at $500/year for up to 100 MAU).

Option 3: Switch to an Editor with Built-In Support

CKEditor 5’s premium tier includes track changes natively. ProseMirror (used by many modern collaborative editors) provides lower-level primitives that you can build track changes on top of, though you still need to build the actual tracking logic. If you haven’t committed to an editor yet, factoring in collaboration requirements during editor selection saves significant integration effort later.

Track Changes vs. Related Concepts: Technical Distinctions

Several features overlap with track changes in developer conversations. The distinctions matter for architecture decisions.

Track Changes vs. Revision History

Track changes records granular, per-operation edits that are pending review. Revision history captures document-level snapshots over time.

As the CKEditor team frames it, track changes “suggests what could be changed in the future,” while revision history “looks at what was already changed in the past.” Revision history provides capabilities that track changes does not: creating named snapshots, diffing between arbitrary versions, and restoring previous states. Most production implementations need both. Track changes handles the editorial review cycle; revision history handles the “oops, we need last Tuesday’s version” scenario.

Track Changes vs. Operational Transformation / CRDTs

If you’re building real-time collaborative editing (multiple users typing simultaneously, Google Docs style), you’ll encounter Operational Transformation (OT) or Conflict-free Replicated Data Types (CRDTs). These are concurrency control mechanisms for real-time multi-cursor editing. Track changes is a review workflow mechanism.

They serve different purposes. OT/CRDTs resolve conflicts when two users edit the same content simultaneously. Track changes makes edits visible for asynchronous review. You can have real-time collaboration without track changes (everyone’s edits just apply immediately) and track changes without real-time collaboration (sequential editing with review passes). Some systems combine both: real-time co-editing with the option to switch into a suggesting/tracking mode.

Track Changes vs. Version Control (Git)

Developers naturally draw this analogy. Both record modifications over time. But track changes operates on a single document with human-readable markup designed for non-technical reviewers. Git operates on file trees with code-level diffs designed for developers. Track changes focuses on one review cycle. Git manages entire histories across branches and merges.

The closer Git analogy for track changes is actually a pull request diff, not the full version control system. Track changes is the equivalent of a PR where someone reviews line-by-line changes and approves or requests modifications.

Track Changes vs. Inline Comments

Track changes modifies content. Inline comments annotate content without modifying it. From an implementation standpoint, they share some infrastructure (both anchor to document ranges, both carry author metadata, both need UI for creation and resolution) but they’re separate features.

The two work best together. A tracked deletion shows what was removed; a comment explains why. Loop Index offers both track changes and inline comments as separate plugins for TinyMCE, Froala, and CKEditor 4.

Integration Architecture Considerations

Once you’ve chosen a track changes solution, there are architectural decisions that affect how it fits into your application.

Persistence Strategy

How do you store documents with pending changes? Two common approaches:

Inline storage: Pending changes are encoded directly in the HTML (via <ins>, <del>, data attributes, or custom elements). When you save the document, you save the marked-up HTML. When you load it, the plugin reads the markup and reconstructs the change state. This is simpler to implement but means your stored HTML contains tracking artifacts that need to be stripped if you render the document outside the editor.

Separate change log: The document’s clean content is stored alongside a separate list of change operations (as JSON, for example). The plugin applies the changes on load and extracts them on save. This is cleaner for storage and rendering but adds complexity to the save/load cycle.

Most plugins use inline storage because it’s more portable and doesn’t require external coordination between two data sources.

User Identity Integration

Track changes needs to know who is making each edit. Your integration layer needs to pass the current user’s identity (user ID, display name, and optionally a color preference) to the plugin at initialization time. This typically happens through the plugin’s configuration API or an initialization callback.

Consider how this interacts with your authentication system. If users can be logged in across multiple sessions or devices, the author attribution needs to remain consistent.

Server-Side Processing

If your application does any server-side processing of document content (sanitization, PDF generation, content extraction for search indexing), you need to account for the tracking markup. A document with pending changes contains extra HTML elements that your server-side logic may not expect. You’ll likely need to either strip tracking markup before processing or make your processing pipelines track-changes-aware.

Permission Model

Not every user should have the same capabilities. Common permission splits:

• Can edit with tracking: all changes are recorded (typical for contributors)
• Can accept/reject changes: authorized to finalize edits (typical for editors or approvers)
• Can edit without tracking: changes apply directly, bypassing the tracking layer (typical for admins or document owners)

Your application’s role and permission system needs to map to the plugin’s API for enabling/disabling tracking and controlling access to accept/reject operations.

Use Cases That Drive Implementation Decisions

Understanding what track changes are in the abstract is useful, but the specific use case shapes how you implement it.

Legal and Contract Platforms

Contract negotiation relies on track changes (called “redlining” in legal contexts). Every insertion, deletion, and revision to contract language needs to be visible to all parties. Redlining workflows typically include insertions, deletions, comments, suggested revisions, version comparisons, and review cycles across legal, sales, procurement, and finance teams. If you’re building a contract management platform on TinyMCE or Froala, track changes isn’t optional. It’s the core feature.

Legal use also raises metadata concerns. Track changes data can expose confidential negotiation strategy if documents aren’t properly cleaned before external sharing. Your application may need a “prepare for external sharing” workflow that strips tracking metadata and produces a clean document.

Regulated Industry Documentation

Pharmaceutical, financial, and healthcare applications that handle controlled documents need auditable edit trails. Track changes satisfies requirements like 21 CFR Part 11 by recording who changed what and when. For these use cases, your persistence layer needs to archive the full change history, not just the final accepted document.

Content Management and Publishing

Publishing platforms, editorial tools, and CMS applications use track changes for editor-to-author review workflows. The volume of changes per document tends to be high, making performance and display mode support important. Experienced editors note that they sometimes want to prevent visual clutter that overwhelms the author, so a simple markup mode or per-reviewer filtering becomes a valuable feature.

SaaS Platforms with Embedded Editors

Any SaaS application that embeds a rich text editor (internal wikis, documentation tools, proposal builders, reporting platforms) will eventually get feature requests for collaborative review. The global team collaboration software market was valued at $36.1 billion in 2024 and is projected to reach $57.4 billion by 2030. Track changes is shifting from differentiator to baseline expectation.

If your platform uses TinyMCE, Froala, or CKEditor 4, explore who benefits from track changes plugins to see how the feature maps to your specific user segments.

Common Implementation Pitfalls

Teams that have shipped track changes integrations consistently report the same pain points.

Undo/redo conflicts. The editor’s native undo stack doesn’t always play well with the tracking layer. Undoing a tracked change needs to reverse both the content modification and the tracking markup. Test undo/redo exhaustively during integration.

Paste handling. Users paste content from Word, Google Docs, web pages, and other sources. Pasted content arrives with its own formatting, and the tracking layer needs to treat the entire paste operation as a single tracked insertion. If your plugin doesn’t handle this, you’ll get partially tracked pastes that corrupt the change history.

Table and list operations. Adding or removing table rows, merging cells, and converting between list types are complex DOM operations. Simpler track changes implementations may not handle them at all, or may track them as a series of confusing low-level insertions and deletions. Clarify which operations your chosen solution supports before committing.

Performance with many changes. Documents with hundreds of pending changes can slow down rendering and make the review experience painful. Ask your plugin vendor about performance characteristics at scale, or test with realistic document sizes during evaluation.

Editor upgrades. When TinyMCE or Froala releases a major update, the plugin needs to remain compatible. Evaluate the plugin vendor’s track record for timely updates and version support.

Frequently Asked Questions

Can you add track changes to TinyMCE, Froala, or CKEditor 4?

Yes, through plugins. These editors don’t include native track changes. Plugins like those from Loop Index add the full accept/reject workflow, author attribution, and change markup to browser-based editing environments. CKEditor 5 offers track changes as a premium built-in feature.

What is the difference between track changes and revision history?

Track changes records individual proposed edits (insertions, deletions, formatting changes) that are pending review. Revision history saves complete document snapshots over time for comparison and restoration. Revision history provides capabilities track changes does not: named snapshots, version diffing, and rollback. Most applications need both.

How are tracked changes stored in web-based editors?

Most plugins store tracking data inline in the HTML using custom elements, data attributes, or standard <ins>/<del> tags enriched with metadata. This means your saved document HTML contains the tracking markup. Some implementations use a separate change log stored alongside the clean document content.

Is redlining the same as track changes?

Functionally, yes. Redlining is the legal industry’s term for the same process: making document edits visible so all parties can review and negotiate proposed changes. The term comes from lawyers marking contract edits in red ink. When building a legal or contract platform, “redlining” and “track changes” refer to the same underlying feature.

Do track changes plugins support real-time collaboration?

Track changes and real-time collaboration are separate concerns. Track changes provides an asynchronous review workflow (propose edits, review later). Real-time collaboration (multiple cursors, simultaneous editing) requires OT or CRDT infrastructure. Some systems support both, but a track changes plugin alone does not make your editor real-time collaborative.

What types of edits can track changes record?

Standard coverage includes text insertions, text deletions, and formatting changes. More complete implementations also track moved text, table operations, and list manipulations. The exact scope depends on the plugin or implementation. Verify operation coverage against your specific use cases during evaluation.

How does track changes integrate with user authentication?

The plugin needs a user identity (typically a user ID and display name) passed through its configuration or initialization API. Your integration layer maps your application’s authenticated user to the plugin’s author model. This ensures every tracked change is attributed to the correct user, which matters for both the review UI and audit trail requirements.