SCEditor: a small WYSIWYG editor that upgrades a textarea in place

Three script tags and one create call

SCEditor is a lightweight WYSIWYG editor for HTML and BBCode, and its integration model is the first thing to understand. It does not replace your form field with a component. It attaches to a textarea that is already in your page.

The assets are a theme stylesheet, the editor script, and one script per output format you want:

<link rel="stylesheet" href="minified/themes/default.min.css" />
<script src="minified/sceditor.min.js"></script>
<script src="minified/formats/bbcode.js"></script>
<script src="minified/formats/xhtml.js"></script>

Then the conversion is a single call, which takes the textarea element and an options object:

var textarea = document.getElementById('id-of-textarea');

sceditor.create(textarea, {
	format: 'xhtml',
	style: 'minified/themes/content/default.min.css'
});

The two options are the ones that matter. The format chooses the dialect the editor speaks, and the style points at the content stylesheet, which is the theme applied to the editing area itself, separate from the toolbar theme in the stylesheet link above.

Reading the contents back is symmetric:

var textarea = document.getElementById("id-of-textarea");

sceditor.instance(textarea).val();

That symmetry is the design point. Your form still posts a textarea field, and the server receives BBCode or XHTML as a string, exactly as it would if a person typed it. Nothing about your backend has to change to gain a rich text editor, which for a forum software with a decade of existing templates is the entire reason to use something like this.

A full list of options is documented separately on the project site.

BBCode is the reason this editor still exists

The format option is not a detail, and choosing wrong here costs you data.

BBCode and XHTML are the two dialects SCEditor speaks, and they are not interchangeable representations of the same thing. BBCode is the square bracket markup that forum software has used for decades, with tags like bold and italic and quote and link. XHTML is the editor's HTML output mode.

A forum that stores posts in BBCode cannot switch to an editor that emits HTML without converting its entire archive, and even then the conversion is lossy in both directions. Formatting that HTML can express and BBCode cannot, such as a heading level or a nested list, has no representation in the target format, so it is either dropped or approximated. An editor that speaks the storage format natively avoids the problem entirely.

The same reasoning applies in reverse. A content management system storing HTML cannot use a BBCode editor, because every post would arrive as markup the renderer does not understand.

So the format flag is a commitment to your data model rather than a rendering preference, and it is the first question to answer. The fact that SCEditor supports a non-HTML dialect at all is what distinguishes it from the large group of WYSIWYG editors that emit HTML and nothing else.

The topic list attached to the repository names bbcode and bbcode-editor alongside wysiwyg and contenteditable, which confirms the positioning. The editor is built on the browser's contenteditable mechanism rather than on an iframe, which is why it can offer a live preview of a dialect the browser does not understand.

Grunt drives the build, QUnit runs the tests

The build tooling is old and that is the most immediately noticeable thing about the project.

You need Grunt installed to run the build and the tests, and the installation is a global npm install of the CLI:

npm install -g grunt-cli

Then the development dependencies:

npm install

And then the three grunt targets do the work:

# Minify the JS and convert the LESS to CSS
grunt build

# Run the linter, unit tests and coverage
grunt test

# Creates the final distributable ZIP file
grunt release

The test target is the interesting one because it bundles three things: the linter, the unit tests and coverage. The unit test runner is QUnit, wired in through a grunt plugin, and the coverage is Istanbul, with the istanbul packages for coverage, instrumentation and reporting listed in the dev dependencies.

There is a dev server for testing changes without a full build, started with npm run dev, which runs a script in the tests directory, and then you open http://localhost:9000/tests/ in a browser. The npm scripts map onto the same grunt tasks, so npm test runs grunt test.

The build itself is a modern stack in an old harness. Rollup bundles the JavaScript through a grunt plugin, UglifyJS minifies it, Less is compiled to CSS, PostCSS and autoprefixer handle the vendor prefixes, and cssnano does the final CSS minification. A separate eslint configuration file at the root, eslint.config.mjs, drives the linting through grunt-eslint, which is the flat config format.

The project also ships a CHANGELOG.txt, which is what you would consult to understand what changed between versions.

A 2026 release on a package that still declares Node 0.10

The release history is the interesting maintenance fact, and it needs reading carefully.

The three most recent releases are v3.2.2 from 2026-10-04, v3.2.1 from 2026-02-06 and v3.2.0 from 2023-03-05. The repository is not archived, the default branch is master, and the last push was on 2026-10-04, the same day as the newest tag. So the project is alive, with a release in the last few weeks.

The gaps between releases are uneven. Nearly three years between 3.2.0 and 3.2.1, then eight months to 3.2.2. That is the pattern of a mature project maintained in bursts, which fits a tool that has been in production on forum software for a decade and a half.

Now the oddities, and they are real.

The package metadata declares engines with node >= 0.10.0, which is a Node version from 2013. The browserslist field asks for the last four versions and ie 10, so the browser support statement also predates the modern browser era. The copyright line in the licence text is 2011 to 2017, and the repository's own top-level entry says the licence is a custom one that GitHub cannot classify, while the readme and the package metadata both say MIT. The licence text itself is the standard MIT wording, so this looks like a stale classification rather than a real licensing question, but the discrepancy is worth noting if you are clearing a licence scan.

The assets tell the other half of the story. The published file list includes the emoticons directory, the languages directory for translations, a development build, the minified build, the src directory, and the changelog, licence and readme. The languages directory is the localisation surface, and the readme asks for contributions in themes, translations, bug reports and fixes, which is a project still actively soliciting community work.

Where a new editor should start instead

For anyone starting something new, the honest recommendation is a different tool, and the reason is not that SCEditor is bad.

The alternatives have moved on. There are contenteditable-based editors that are framework components with their own plugin ecosystems, and there are editors that emit Markdown, and there are the modern rich text libraries that are maintained by large organisations. Each of those is a better default for a new project, and none of them needs a global CLI installed to build.

What SCEditor still does that they largely do not is BBCode. If your storage format is BBCode, the choice is much narrower, and this library is one of the few that speaks it natively.

The second case is the legacy application. If you have a form with a textarea on it, a server that stores the posted string, and templates you would rather not rewrite, then SCEditor's attach-to-textarea model is precisely right. You add a stylesheet and three script tags, call create, and the form keeps working. A component-based editor that wants to own the value and call your onChange is a worse fit for that situation, because it asks for a change to the form plumbing.

The third consideration is the age of the stack. Grunt with a global CLI, Less, UglifyJS, Istanbul and a jQuery-flavoured keyword list describe a build from around 2015, and the browserslist entry naming Internet Explorer 10 confirms the era. The code itself is maintained, but a contributor picking this up inherits a toolchain that most new projects have moved past, and the effort of refreshing it is not small.

So the decision is really about the format and the shape of the existing page, not about the editor's quality.

Editorial conclusion

SCEditor suits a forum or wiki that needs a WYSIWYG editor writing BBCode rather than HTML, or a legacy application that wants to add rich text to an existing form without replacing its backend. It does not suit a new project, because a decade of newer editors exist, it does not suit a team that needs a framework-integrated component rather than a standalone script, and its own package metadata still targets Node 0.10 and Internet Explorer 10. Before adopting it, test the round trip of your chosen format, since converting between BBCode and XHTML is where this kind of editor loses data, and check the 3.2.2 release notes for the current behaviour.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. samclarke/SCEditor on GitHub