TinyMCE Version History 2026 | Changelog & Revision Guide

TL;DR

TinyMCE version history refers to the timeline of TinyMCE editor releases, from version 5 through the current version 8.5.0. But the phrase is confusing because TinyMCE also has a Revision History plugin that tracks document versions, not software versions. This guide explains both meanings, covers what changed in each major release, and helps you decide whether to upgrade and what collaboration features you actually need.

What Does TinyMCE Version History Mean?

The term “TinyMCE version history” sounds straightforward, but it maps to two completely different things depending on context.

The first meaning is the software release timeline. This is the record of TinyMCE editor releases: major versions, minor versions, patch releases, changelogs, release notes, support dates, and breaking changes. The TinyMCE changelog is the canonical source for the community edition, while TinyMCE release notes cover Tiny Cloud and Enterprise releases.

The second meaning is document-level revision history. TinyMCE’s Revision History plugin lets users view saved versions of a document, compare differences between versions, and restore older content. This is a premium plugin, not a changelog.

The distinction matters because developers searching for TinyMCE version history often land on the wrong page. If you need to know what changed in the editor software, you want the changelog. If you need Google Docs-style version snapshots for your users’ documents, you want the Revision History plugin.

Here is a quick reference for the related terms:

Term	What it means
TinyMCE version history	Timeline of TinyMCE editor releases
TinyMCE changelog	Detailed list of community-edition changes by version
TinyMCE release notes	Broader Tiny Cloud / Enterprise release explanations
Revision History	TinyMCE plugin for viewing and restoring saved document versions
Suggested Edits	TinyMCE plugin for accept/reject review workflows
Track changes	Review workflow for proposed insertions, deletions, and modifications
Inline comments	Text-anchored feedback threads for reviewer discussions

TinyMCE Version History vs. Revision History

This is where most confusion happens. The TinyMCE version history is about the editor itself. “TinyMCE 8.5.0 fixed URI handling and improved screen reader announcements” is software version history. That information lives in the changelog.

TinyMCE’s Revision History plugin is about documents. “Version 12 of a policy document was restored by an editor” is document revision history. The plugin requires a revisionhistory_fetch callback that returns saved revisions as an array of objects, each containing a revisionId, createdAt timestamp, optional content, and optional author data. It supports three revision types: initial (generated when TinyMCE loads), draft (reflecting the current unsaved state), and saved (fetched from your storage backend). Source

Neither of these is the same as track changes, where a reviewer proposes specific edits that another user accepts or rejects. And neither is the same as inline comments, where reviewers attach discussion threads to specific text ranges.

A practical way to think about it:

• “What changed in the editor?” = Release history (changelog, release notes)
• “What did this document look like before?” = Revision History plugin
• “Should this proposed edit become final?” = Track changes or Suggested Edits
• “Why does the reviewer disagree with this sentence?” = Inline comments

Where to Find the Official TinyMCE Version History

TinyMCE splits its version history across several documentation pages, and each one serves a different purpose.

Changelog. The TinyMCE Community version changelog lists changes by version for the open-source community edition. It covers additions, improvements, bug fixes, and deprecations. If you use Tiny Cloud or TinyMCE Enterprise, the changelog directs you to release notes for the full picture.

Release notes. The TinyMCE 8 release notes provide more narrative coverage, including premium plugin changes, known issues, and breaking changes for each release. These are more useful for product managers and engineering leads who need context, not just a list of commits.

Support docs. The TinyMCE support page lists supported versions, premium-support end dates, and security-update policies. This is essential reading before any upgrade decision.

Migration guides. TinyMCE publishes migration guides that cover architectural changes, removed plugins, renamed APIs, and breaking changes between major versions. If you are moving from TinyMCE 5 or 6 to TinyMCE 8, start here.

Version compatibility reference. The plugin compatibility docs show which premium plugin versions work with which TinyMCE versions. Check this before combining an editor upgrade with premium or third-party plugins.

TinyMCE Major Versions at a Glance

Version	Release date	Why it matters
TinyMCE 8	8.0.0 on July 23, 2025; latest is 8.5.0 on April 29, 2026	Current major version. New T8LK: license keys for commercial self-hosted. Suggested Edits plugin. Language-code standardization.
TinyMCE 7	7.0 on March 20, 2024	Revision History, Markdown, Document Converters. GPLv2+ licensing with new license_key setting.
TinyMCE 6	6.0.0 on March 3, 2022	IE11 dropped. Major plugin ecosystem changes. Security support has ended.
TinyMCE 5	5.0.0 on February 4, 2019	Legacy. No security updates except through dedicated LTS agreements.
TinyMCE 4	Legacy	Support ended December 31, 2020. Treat as technical debt.

Sources: TinyMCE 8.0 release notes, TinyMCE 7 release highlights, TinyMCE 6 changelog, TinyMCE 5 changelog, TinyMCE 4 support window

What Changed in TinyMCE 8

TinyMCE 8 is the current major version. Bug fixes and new features are always released in the latest version, which as of May 2026 is TinyMCE 8. Source

License key changes

Commercial self-hosted deployments must now use T8LK:-prefixed license keys. This is a breaking change from TinyMCE 7’s licensing system. If you self-host TinyMCE commercially, you need to update your license key configuration before upgrading. Source

Suggested Edits

TinyMCE 8.0 introduced the Suggested Edits premium plugin, which lets multiple users propose changes, provide feedback, and accept or reject suggestions. The plugin supports access levels (full, feedback, read, none) and can persist models across sessions via suggestededits_model. Source

Language code standardization

TinyMCE 8.0 standardized language codes to RFC5646/BCP47 format, using hyphens (en-US) instead of underscores (en_US). Both formats work in TinyMCE 8 with a console warning, but TinyMCE 9 will support only the hyphenated format. Source

TinyMCE 8.5.0

The latest release, 8.5.0 (April 29, 2026), added a new content_language option and updated Spell Checker behavior to use it as the default proofing language. It also improved inline diff highlights in Suggested Edits and TinyMCE AI, and fixed issues with URIs, screen reader announcements, selections, lists, and DOMPurify handling. Source

What Changed in TinyMCE 7

TinyMCE 7 is the inflection point for two things that come up constantly in TinyMCE version history searches: document revision history and GPL licensing.

Revision History plugin

TinyMCE 7.0 introduced the Revision History premium plugin, letting users compare two versions of content and view additions, changes, and deletions between them. Source

Markdown and document converters

TinyMCE 7 added a Markdown plugin and document-conversion features, including Import from Word, Export to Word, and Export to PDF. Source

GPL licensing shift

This is the change that generated the most community discussion. TinyMCE 7.0 moved from an MIT license to GPL Version 2 or later and introduced the license_key configuration setting. Self-hosted users must now declare either GPL usage or authenticate a paid Tiny license. Source

On Hacker News, developers debated whether applications integrating TinyMCE would need to distribute combined works under GPL, and whether separating TinyMCE as a plugin changes the analysis. Source

Practitioners on Reddit report that this license change caused some teams to stay on TinyMCE 6, accepting the tradeoff of losing updates and premium-plugin compatibility rather than navigating the GPL implications. Source

Why Support Windows Matter More Than Release Dates

When reviewing TinyMCE version history, support windows should carry more weight than release dates. Here is the current picture:

• TinyMCE 8.5: Released April 29, 2026. Premium support ends October 29, 2027.
• TinyMCE 8.0: Released July 23, 2025. Premium support ends January 23, 2027.
• TinyMCE 7.0: Released March 20, 2024. Premium support ends September 20, 2025.
• TinyMCE 6: Security support for the free open-source version ended October 31, 2024. Commercial security support ended June 6, 2025.
• TinyMCE 5: No longer receives security updates except through a dedicated LTS agreement.

Source

If your application still runs TinyMCE 6, you are on an unsupported version with known security exposure. TinyMCE 5 is in even worse shape. These are not just technical details. They affect compliance, security posture, and the risk profile your team presents to stakeholders.

Version History and Collaboration Workflows

Many people who search for TinyMCE version history are actually trying to solve a collaboration problem. They want their users to review, discuss, or roll back content. Understanding what each collaboration feature does helps you pick the right tool.

Need	Feature	What it answers
View old saved versions of a document	Revision History	“What did this document look like last week?”
Accept or reject proposed changes	Track changes / Suggested Edits	“Should this edit become permanent?”
Discuss a specific text range	Inline comments	“Why does this paragraph need to change?”

TinyMCE’s Revision History plugin handles the first need. It works with saved snapshots fetched via callbacks and displays visual diffs. Source

TinyMCE’s Suggested Edits plugin (introduced in 8.0) handles part of the second need, with model persistence and review access levels. Source

But many teams need something different from what ships with TinyMCE. A developer posting on Reddit’s npm community described the pain point clearly: many comment plugins force you into a specific UI, storage model, or workflow, while custom applications often need events, their own backend, permissions, mentions, and threading. Source

If your workflow requires Word-like revision tracking in TinyMCE, Loop Index provides a dedicated TinyMCE Track Changes plugin built for teams that need collaborative editing with accept/reject functionality. For text-anchored discussions, Loop Index also offers a TinyMCE Inline Comments plugin that gives developers control over storage, permissions, and UI without being locked into a specific backend.

How to Choose or Pin a TinyMCE Version

TinyMCE’s cloud loading system gives you three options for version control.

Float the major version. Loading from /tinymce/8/tinymce.min.js always fetches the latest verified TinyMCE 8 release. This is convenient but means your editor can change without you explicitly approving it.

Pin a minor or patch version. Loading from /tinymce/8.1/tinymce.min.js or /tinymce/8.1.2/tinymce.min.js locks you to a specific release. This is the safer choice for regulated workflows, heavy custom plugins, or applications where content serialization must stay consistent.

Testing and dev channels. TinyMCE also offers 8-testing (release candidate) and 8-dev (nightly builds from the repository). These are not for production. Source

The practical advice: pin your version if collaboration features, custom plugins, or content filtering are business-critical. Float only if you have a QA process that catches regressions quickly.

Licensing and Self-Hosting: The Part Official Pages Under-Explain

Licensing is one of the most confusing aspects of TinyMCE version history, and the official docs, while accurate, assume a level of context that many developers lack.

TinyMCE’s license-key documentation distinguishes two license types: GPL and commercial. Cloud-only deployments require an API key for cloud services, premium plugins, and automatic updates. Self-hosted deployments require a GPL or commercial license key and do not need an API key. TinyMCE does not contact any server to validate license keys for self-hosted deployments. Source

If a valid license key is not provided, the editor can be disabled and a console warning or editor notification persists until a valid key or gpl is supplied. Source

Practitioners on Reddit consistently show confusion about this setup. One user in a self-hosted thread was puzzled because TinyMCE’s site appears to sell plans while also offering open-source self-hosted downloads, and a commenter summarized the practical difference as simply whether you provide a license key in the config. Source

Stack Overflow questions reinforce this. A question about TinyMCE 7.7.1 in a self-hosted .NET MVC app shows how license-key setup can trigger UI warnings even when the developer believes they are running a GPL self-hosted setup. Source

Important: Licensing has business and legal implications. Consult your legal team before using GPL mode in a proprietary commercial application.

Deployment Costs Are Part of Version History Too

Version history and deployment choices are connected in ways that official documentation does not always make clear. TinyMCE Cloud uses an editor-load model for pricing, and this has caused some teams to rethink their architecture.

In a Reddit webdev thread, a SaaS user with around 100,000 editor loads per month said TinyMCE’s load-based pricing did not fit their use case and they moved to Froala. Another commenter said a pricing change would have taken them from $0 to over $4,000 per year for a basic-editor use case. Source

One practical workaround from the community: render a read-only placeholder first and load TinyMCE only when a user clicks to edit. One developer reported this reduced their editor loads from 30,000 down to about 500. Source

These architecture decisions interact with version history because switching from cloud to self-hosted (or vice versa) often coincides with a major version upgrade, and both changes carry risk if handled at the same time.

If you are evaluating collaboration plugins alongside a TinyMCE version change, check Loop Index pricing to understand how track changes and inline comments licensing works on a per-MAU basis rather than per-editor-load.

Upgrade Checklist Before Changing TinyMCE Versions

Before upgrading, work through this list:

1. Identify your current TinyMCE version. Check via tinymce.majorVersion and tinymce.minorVersion in the browser console, your package manager lockfile, or your CDN URL path.
2. Determine your hosting model. Cloud, self-hosted, or hybrid. This affects licensing, version pinning, and plugin loading.
3. Check support status. Is your current version still receiving security updates? Source
4. Review migration guides. TinyMCE’s migration guide from 5 to 8 covers architectural changes, UI updates, stricter security defaults, and updated plugin structures. Source
5. Audit your plugin list. The plugin ecosystem changed significantly in TinyMCE 6, with many plugins removed, integrated into core, or moved to premium-only. Plugins like paste, hr, table, and noneditable were absorbed into core, while bbcode, legacyoutput, imagetools, and others changed status or were removed entirely. Source
6. Check license-key requirements. TinyMCE 7 requires a license_key setting. TinyMCE 8 commercial self-hosted deployments need T8LK:-prefixed keys.
7. Test custom skins, toolbars, dialogs, paste behavior, and content filtering. These are the most common breakage points.
8. Test collaboration workflows. If your application uses revision history, comments, track changes, or suggested edits, verify that these still function after the upgrade.
9. Pin the new version in staging before production rollout.

Common Mistakes When Working with TinyMCE Version History

Confusing software versions with document versions

The TinyMCE changelog tracks what changed in the editor. The Revision History plugin tracks what changed in a document. They are separate concerns with separate data models.

Upgrading without checking plugin changes

Developers who jump from TinyMCE 5 to 8 without reading the migration guide frequently discover that plugins they relied on no longer exist or have moved behind a paywall.

Ignoring license changes

The MIT-to-GPL shift in TinyMCE 7 and the T8LK: key requirement in TinyMCE 8 are not just administrative details. They can block deployments or create compliance issues.

Assuming Revision History is track changes

Revision History shows saved snapshots. Track changes and Suggested Edits show proposed modifications that need approval. These are different workflows solving different problems. If your users need to propose edits and have someone accept or reject them, you need track changes, not revision history.

Letting the cloud version float without QA

Loading /tinymce/8/ gives you the latest verified release automatically. For applications with regulated content or complex collaboration features, this is a risk. Pin your version and test before moving.

How TinyMCE Version Numbers Work

TinyMCE follows semantic versioning conventions. TinyMCE’s own release blog spells it out: major releases (like 7.0 or 8.0) can include breaking changes, minor releases (like 8.5) introduce new features and bug fixes while remaining backward compatible, and patch releases (like 8.3.2) fix bugs and stay backward compatible. Source

In practice:

• 8.0.0 = major release. Expect breaking changes. Read migration guides.
• 8.5.0 = minor release. New features, safe to upgrade with testing.
• 8.3.2 = patch release. Bug fixes only. Generally safe.

The version number tells you how much caution to apply before upgrading.

Deciding What You Actually Need

If you arrived here searching for TinyMCE version history, take a moment to clarify what you are trying to do. The answer determines where to go next.

“I need to know which TinyMCE version I am running.” Check tinymce.majorVersion in the browser console, review your CDN URL, or check your package.json lockfile. Stack Overflow has a long-running thread on this exact question. Source

“I need to upgrade TinyMCE.” Start with the support page to check your current version’s status, then read the migration guide for your version range.

“I need my users to see old document versions.” You want TinyMCE’s Revision History plugin.

“I need my users to propose, accept, and reject edits.” You want a track changes workflow. TinyMCE offers Suggested Edits as a premium plugin, or you can evaluate Loop Index’s TinyMCE Track Changes plugin for a solution built around developer control over storage and UI.

“I need my users to leave comments on specific text.” You want an inline comments solution. Loop Index’s TinyMCE Inline Comments plugin is built for this, with support for mentions, threading, and custom permissions.

“I am comparing editors.” If you are evaluating alternatives alongside TinyMCE, Loop Index also supports Froala Track Changes and Froala Inline Comments.

Have questions about which collaboration approach fits your application? Contact Loop Index to discuss your requirements.

FAQ

What is TinyMCE version history?

TinyMCE version history is the record of TinyMCE editor releases, covering major versions (5, 6, 7, 8), minor versions, patch releases, changelogs, release notes, support dates, and breaking changes. The phrase can also refer to the Revision History plugin, which tracks document versions rather than software versions.

What is the latest TinyMCE version?

As of May 2026, TinyMCE 8 is the current major version. The latest release is TinyMCE 8.5.0, released on April 29, 2026. Source

Where is the official TinyMCE changelog?

The official changelog is in the TinyMCE documentation, labeled as the TinyMCE Community version changelog. For Tiny Cloud and Enterprise releases, TinyMCE directs users to the separate release notes section.

Is TinyMCE Revision History the same as track changes?

No. Revision History shows saved snapshots of a document over time and displays visual diffs between them. Track changes (and TinyMCE’s Suggested Edits plugin) shows proposed edits that can be accepted or rejected before they become permanent. They solve different problems in a collaborative workflow.

What version introduced TinyMCE Revision History?

Revision History was introduced with TinyMCE 7.0, released on March 20, 2024. Source

Is TinyMCE 6 still supported?

Security support for the free open-source version of TinyMCE 6 ended on October 31, 2024, and commercial security support ended on June 6, 2025. Teams still running TinyMCE 6 should plan a migration to TinyMCE 8. Source

Should I pin my TinyMCE version?

For production applications with custom plugins, regulated content, or collaboration workflows, pinning a minor or patch version reduces the risk of unexpected changes. TinyMCE Cloud lets you specify exact versions in the CDN URL path. Source

What changed about TinyMCE licensing in versions 7 and 8?

TinyMCE 7.0 moved from MIT to GPL Version 2 or later and introduced the license_key configuration setting. TinyMCE 8.0 introduced a breaking change requiring commercial self-hosted deployments to use T8LK:-prefixed license keys. Both changes affect how you configure and deploy the editor. Source