Auditing Editor42
The whole promise of Editor42 is that it is the same proven, battle-tested code as TinyMCE 6.8.6 — the open-source WYSIWYG editor millions already rely on — kept on an MIT license and patched for security. A promise like that is only worth something if it can be checked. So we built the project to be open to inspection, and this page lays out what changed, why, and where anyone could look to confirm it. We illustrate it with our first release, 42.0.0.
Verifiable by design
We are not asking you to take our word for any of this — and, realistically, we are not asking you to spend your weekend reading diffs either. The point is quieter than that, and we think stronger: everything that matters is small, public, and legible enough that anyone can check it. The value of Editor42 is not that you personally audit it; it is that the possibility is always there, for you and for everyone else looking at the same code. Changes that try to hide something tend not to survive that kind of daylight for long — and that is exactly the assurance an open, minimal fork is meant to give you.
That only works if the changes stay few and easy to follow. Keeping them that way is the whole design.
What changed in the first release (42.0.0)
The complete main-branch history for 42.0.0 — every commit from the fork to the release.
Editor42's source lives in editor42com/editor42, and the main branch begins from the TinyMCE 6.8.6 source tree — so its commit history is the complete delta, with nothing hidden behind a squashed import. For 42.0.0 the substantive history is short enough to take in at a glance, and the commit graph alongside lays it out in full. It opens with four housekeeping commits: the first three rebrand the editor, and the fourth decouples it from the upstream hosted cloud and paid services.
After those come the security commits — a DOMPurify dependency upgrade, followed by six individual CVE fixes, two cherry-picked from upstream's MIT-licensed patches and four written by us — each in its own commit, so it can be read on its own and traced back to its origin. A single closing commit then sets the version from 6.8.6 to 42.0.0 and updates the changelog.
That is the entire substantive history: a rebrand, a cloud detachment, seven security fixes, and a version bump. The whole of it can be read line by line, or seen at a glance by diffing main against the TinyMCE 6.8.6 baseline it was forked from. The editor's logic is otherwise identical to the version already running in production for millions of people — and the short history is what lets anyone confirm that for themselves.
Every fix comes with tests
Security fixes are easy to claim and harder to trust on faith, so each one is covered by automated tests. Those tests live in the same public source tree; they can be read next to the fix and run against the code, so the question "does this patch actually do what it says, without breaking anything around it?" has an answer you can see rather than assume. They sit on top of TinyMCE's existing, mature test suite — the same battery of tests that has guarded this editor's behavior for years.
Confirming the rebrand changed nothing else
Alongside main, the repository has an editor42 branch that carries the full brand rename — the tox-tinymce container classes, the window.tinymce global, and so on — produced by a preprocessor whose rules are spelled out in our Technical Details & Compatibility article. Comparing editor42 against main produces a large diff by line count, but every changed line is either a brand string or one of a handful of compatibility shim lines at the very end. The same holds at the level of the shipped files: the build repository editor42com/editor42-dist publishes an editor42.js / editor42.min.js build from each branch — TinyMCE-named internals from main, the full rename from editor42 — and the two readable builds differ only in those same brand strings and trailing shims. Plenty of surface churn, no change in behavior — visible right down to the file your browser actually loads.
Here is what that divergence actually looks like. Below are representative spots from the shipped minified bundles: every red token is a string that the main build ships — the same string TinyMCE's own tinymce.min.js carries — and the green token beside it is exactly what the editor42 build puts there instead. The code on either side of each swap is identical, character for character.
Diff sample of the main and editor42 builds of editor42.min.js
The same, release after release
The first release is the only one that carries those opening rebrand-and-detachment commits. After 42.0.0, each release adds just the new fixes — with their tests — on top of the one before it, and ends with the same kind of commit that bumps the version and updates the changelog. So the history stays short and the picture stays the same: a small, readable set of changes between any version and the last, open to anyone who cares to look.
Where to go next
For the exact rename rules, the compatibility shims, and the full compatibility guarantees, see our Technical Details & Compatibility article. If you want the reasoning behind the project — why an MIT-licensed fork exists at all — start with Motivation & Goals. The full list of fixed vulnerabilities, release by release, lives on the Security page.