ckeditor4-releases: the built CKEditor 4 distributions, and the support clock behind them

A distribution repository, not a source tree

The README says what this repository is in one line: it contains the official release versions of CKEditor 4. That distinction matters more than it sounds.

There is no build system here to run, no compiler configuration, no dependency graph to resolve. What is in the tree is the artefact: a completed ckeditor.js bundle, the plugins directory, the language packs, the skins, the adapters, the sample pages. The README states that all versions available in this repository were built using CKBuilder, so they are optimized and ready to be used in a production environment.

The package.json makes the same point from the package manager's side. The package is named ckeditor4, its version in the checked out tree is 4.25.2, its main entry point is ckeditor.js, its description is a JavaScript WYSIWYG web text editor, and the author field names CKSource. There is also a composer.json and a bower.json at the root, so the same build can be consumed by three different package ecosystems.

For an engineer, the practical reading is that you are dealing with a vendored dependency, not with a library you compile. That has consequences. You cannot patch a plugin inside the bundle and expect the change to survive, because the tree is regenerated for each release. You can, however, choose exactly which release you vendor and pin it.

The topics confirm the category: wysiwyg, wysiwyg-editor, wysiwyg-editors, ckeditor4.

End of life in 2023, with paid support until December 2026

The first section of the README is the one that should drive the decision, and it is titled with a warning about the end of life and the extended support model.

The facts are these. CKEditor 4 was launched in 2012 and reached its End of Life on June 30, 2023. A special edition, CKEditor 4 LTS, is available under commercial terms through what the README calls the Extended Support Model, for anyone looking to extend the coverage of security updates and critical bug fixes. With CKEditor 4 LTS, security updates and critical bug fixes are guaranteed until December 2026.

So the product line has a published end date, and it is close. Whatever the state of this repository, the code in it is a platform whose upstream support window is measured in months from the perspective of a reader in late 2026. The three possibilities are straightforward. If you already run CKEditor 4 and cannot migrate now, the LTS edition is the way to keep security patches arriving, and the cost is a commercial licence. If you run CKEditor 4 and do not want to pay, you are accepting an editor with no security coverage. If you are choosing an editor for a new project, this repository is the wrong place to start.

Note also the distinction the README draws between the two: the LTS edition covers security updates and critical bug fixes. That is narrower than active development, and it does not mean new features.

The release history supports the same picture. The last push to the repository was on 2026-07-10, and the tree carries a CHANGES.md and a SECURITY.md file, so the maintenance that does happen is release management rather than feature work.

Four presets that differ in what is inside ckeditor.js

The README explains that there are four versions for each release, named standard-all, basic, standard and full. They differ in the number of plugins that are compiled into the main ckeditor.js file as well as the toolbar configuration, and there is a comparison of the basic, standard and full installation presets on the CKEditor site for more detail.

The standard-all build gets its own paragraph, and the distinction is easy to miss. It includes all official CKSource plugins, but with only those from the standard installation preset compiled into the ckeditor.js file and enabled in the configuration.

That is a meaningful engineering difference. A single-file editor with everything compiled in is convenient to drop on a page, at the cost of shipping plugins the page never uses. The standard, basic and full builds are compiled down to a specific preset, with a matching toolbar, which is how you get a smaller payload and a predictable interface.

The repository root shows the anatomy of a build. There is ckeditor.js, the bundle itself, plus config.js for the configuration entry point, contents.css and styles.js for the base styling, a plugins/ directory for the compiled-in features, lang/ for the language packs, skins/ for the interface themes, adapters/ for the integration points, and vendor/ for bundled third-party code. There is also samples/ with a toolbar configurator among its subdirectories, and the bower, composer and npm manifests alongside the package.json.

So choosing a preset is a real decision with a measurable effect on what you ship, and the repository documents exactly which knobs produce which build.

Branches and tags are the pinning mechanism

If you are vendoring this, the interesting part of the repository is how it names things, because that is how you make a deployment reproducible.

The branches are organised in layers. The master and latest branches hold the latest release of the standard-all preset, including betas, while stable holds the latest stable release of the same preset, without betas. A branch named A.B.x, for example 4.3.x, holds the latest release of the standard-all preset in that A.B branch. The same three shapes are repeated per preset: stable, latest, and A.B.x, for example basic/4.0.x, and the README describes those as the latest stable release tag point, the latest release tag point including betas, and the latest releases in the A.B branch.

The tags changed once, and the change matters if you maintain an old deployment. Since version 4.3.3 the naming rules are x.y.z for the standard-all build, such as 4.3.3 or 4.4.0, and preset/x.y.z for a specific preset, such as basic/4.3.3. The version numbers follow the Semantic Versioning 2.0.0 scheme. Up to version 4.3.2 the tags had the opposite order, x.y[.z] followed by the preset, for example 4.0/basic or 4.0.1/standard, and the convention changed in 4.3.3 to conform to SemVer.

In practice, a build server pinning by tag wants the newer form, and any script that assumes the older form will break on older versions. The semver compliance is the useful part for a team with a dependency scanner: a patch bump is a patch bump.

Installing means choosing a branch or a tag

The installation section gives two git routes and points at the package managers for the third.

To install one of the available releases by cloning, the README says to clone the repository and switch to the respective branch:

	git clone -b <release branch> git://github.com/ckeditor/ckeditor4-releases.git

If you already use git for your project and want to integrate CKEditor, the recommendation is to add the repository as a submodule, which needs two commands:

	git submodule add -b <release branch> git://github.com/ckeditor/ckeditor-releases.git <clone dir>
	git commit -m "Added CKEditor submodule in <clone dir> directory."

The submodule route is the interesting one for a team, because it records the exact commit you depend on inside your own repository, and it lets you point at a branch rather than copying files by hand. The clone route is a one-off copy that will drift the moment anyone updates it.

The third route is the package managers. The README points to an article on installing CKEditor with package managers covering Bower, Composer and npm, and the presence of bower.json, composer.json and package.json at the root is what makes those routes work.

Whichever route you take, the README gives you a way to check the result. The editor comes with a sample page that can be used to verify if the installation succeeded, in the samples directory, and you call it in your browser at:

	http://<your site>/<CKEditor installation path>/samples/index.html

That page is worth using on every upgrade, because a preset change or a plugin change shows up there before it shows up in your application.

Cloning a branch versus installing from npm

The README offers both, and the difference in approach is worth spelling out, because it changes what your upgrade process looks like.

Cloning a release branch gives you the complete tree: the bundle, the plugins directory, the language packs, the skins, the adapters and the samples, with a branch you switch between. Nothing is resolved at install time, and nothing is version-checked by a package manager. The tradeoff is that your repository becomes the place where the editor version is decided, and switching to a different release means a git operation rather than a dependency update.

Installing from npm or Composer gives you the same artefact through a dependency manager, which means the version constraint lives in your manifest, the tree can be audited by your usual tooling, and updating is a matter of changing a version number. The cost is that you consume the package rather than own the files, and the repository's branch and tag scheme stops being the thing you manage.

For a team already running a modern package manager, the second is the smaller process. For a team with an existing submodule convention or a policy of vendoring everything, the first fits the tooling they already have.

A third consideration applies to both. The samples directory should survive whichever route you take, at least in a staging environment, because the README presents it as the installation check. And whichever route you use, the preset you pick is the one your page will load, so a change of preset is a change of behaviour that the sample page will show you before your application does.

Licensing is a choice of three, and the licence file is the detail

The licence section is short and unusual in a good way. The editor is licensed under the GPL, LGPL and MPL licences, at your choice, and the README asks you to check the LICENSE.md file for more information. GitHub records the repository licence as a custom one it cannot classify automatically, which is what happens when a single tree carries three licences and lets the licensee pick.

The practical effect is that the choice is yours rather than the vendor's, which is the part that matters for an organisation with an open source review process. Which of the three you pick affects what obligations you take on, particularly around redistribution and modification, and that is a question for whoever owns that policy rather than for this page. What this README tells you is where the text lives: LICENSE.md in the repository root.

Two other files in the tree are worth knowing about. SECURITY.md sits at the root, which is where a security disclosure process is described, and CHANGES.md records what changed in each release. On an end-of-life product, the changelog and the security file are the two places where you would look to understand what a given build contains.

The last push was on 2026-07-10, which tells you the release line is still being cut. It does not change the June 30, 2023 end of life date, and it does not extend the December 2026 guarantee on paid fixes.

Editorial conclusion

ckeditor4-releases fits a team with an existing CKEditor 4 integration that needs a pinned, reproducible build it can vendor or install from npm, and that has either budgeted the commercial LTS or accepted the risk of an unpatched editor. It does not fit a new project choosing an editor today, because the platform itself is in end of life. Verify first which branch or tag your deployment should pin, whether your copy came from the standard-all, standard, basic or full preset, and who is paying for the extended support that keeps security fixes arriving until December 2026.

Frequently asked questions

Official sources

1. ckeditor/ckeditor4-releases on GitHub
2. Issues
3. README