SunEditor: a no-dependency WYSIWYG editor with a modular plugin system

An editor that adds no runtime dependencies to your project

SunEditor's most concrete claim is that it pulls in no third-party packages at runtime. Most rich text editors depend on external libraries: Quill uses Parchment, ProseMirror relies on its own family of modules, and TipTap requires Vue or React as peers. Examining package.json at the repository root confirms there are no production dependencies, only devDependencies used for building and testing.

That constraint has a direct consequence for architecture. Text formatting, media embedding, table editing, and LaTeX math are all handled without delegating to another library. Swapping its internal parser or serialiser for a third-party alternative is not possible, because no third-party components exist inside it to replace. Projects that want control over their dependency surface find this arrangement useful; projects that need to share serialisation logic with another library will find the boundary harder to cross.

v3 sets the browser floor at Chrome 119, Firefox 125, and Safari 17.2

Eight browser targets appear in the support table with specific version requirements. Chrome 119 and Edge 119 are required, both from October 2023. Firefox 125, from April 2024, is the minimum for that browser, and Safari 17.2 on both macOS and iOS, from December 2023, is listed alongside Opera 105, Android WebView 119, Samsung Internet 23.0, and Firefox ESR 128. No polyfills ship by default, and the README explains the baseline as targeting features commonly available after late 2023.

Adding support for older browsers falls entirely to the consuming project. Internet Explorer and the original Legacy Edge are marked as not supported, with no configuration option to extend the floor. Any project that must support IE has to stay on the v2-legacy branch or choose a different editor. Adding your own polyfills is possible in principle, but the README leaves the scope of that work unspecified.

Installing via npm and writing the first create call

Installation requires one command.

npm install suneditor --save

A minimal setup involves two CSS imports and a create call. The first import covers the editor UI; the second, which the README marks as optional, covers how editor-generated HTML looks when rendered outside the editor frame.

import 'suneditor/css/editor';
import 'suneditor/css/contents';
import suneditor from 'suneditor';

suneditor.create(document.querySelector('#editor'), {
    // options
});

Passing either a div or a textarea to create is valid, and no additional build or initialisation step is required before that call runs. Plugin configuration, toolbar layout, and behaviour settings all go into the options object shown here as empty.

For projects without a module bundler, the CDN path uses jsDelivr: a script and a stylesheet from cdn.jsdelivr.net, then SUNEDITOR.create instead of suneditor.create. CDN examples in the README pin to @latest as the version string, which means the version delivered can change between page loads whenever the package is updated on npm.

The plugin list controls what ships in the bundle

SunEditor includes plugins for @Mentions with autocomplete, advanced table editing with custom layouts, Math in LaTeX syntax, a drawing canvas, code blocks with a language selector, a Markdown view mode using GitHub Flavored Markdown, media galleries for image, video, audio, and file types, PDF export, templates, and embedded audio, video, and iframe content. Only the plugins configured in the options object are loaded, which is how the architecture keeps the bundle small when not every feature is used.

The README does not document how much each plugin contributes to the delivered bundle size, so the actual weight for a given feature selection is only visible after a build. A project enabling all plugins gets everything; a project enabling only a basic toolbar gets considerably less. ARCHITECTURE.md covers the plugin interface in more depth than the README does, and it is the right file to read before writing a custom plugin.

strictMode governs what happens to HTML outside the editor's content model

SunEditor is built for structured content: articles, documentation, and emails. Content is validated and auto-corrected to maintain consistency, which means HTML that does not fit the editor's expectations gets rewritten rather than passed through. That is a different category of behaviour from editors that preserve markup as given.

For projects that must round-trip arbitrary HTML attributes, custom tags, or non-standard structure, the relevant setting is strictMode. The README does not define strictMode inline; it points to ARCHITECTURE.md for the content filtering details, making that file a required read before integration begins. An editor that silently rewrites markup on input creates bugs that are hard to reproduce and harder to trace to their source, because the rewrite happens inside the editor rather than on save.

What the v2-legacy branch status actually means for IE11 users

The README describes v2-legacy as no longer actively maintained, kept available for projects that need IE11 support. Version 2.47.12 appeared on 2026-09-08, the same date as v3.3.3, which contradicts the stated maintenance posture directly.

What 2.47.12 changes is not described in the top-level repository view. The file changes.md at the repository root is where to look; checking it before treating the branch as frozen is a more reliable approach than taking the README's description at face value.

For a team on v2-legacy, the gap between the README's description and the actual state matters before any migration decision. The v2-to-v3 shift also drops IE11 entirely and sets the browser floor at late 2023 versions, so teams with IE11 users have no upgrade path within SunEditor and have to weigh that constraint against what v3 offers.

React and Vue ship as separate wrapper packages, Svelte does not get a link

Framework integration beyond plain JavaScript is covered by two official wrapper packages: suneditor-react at github.com/JiHong88/suneditor-react and suneditor-vue at github.com/JiHong88/suneditor-vue. Both are listed in the README's Framework Integration section and are maintained by the same author as the core editor.

The README also lists Svelte as a supported framework but gives no package link for it. Whether that integration comes from a community package, direct use of the vanilla JavaScript API, or something else is not documented, and a project targeting Svelte has to find that answer outside the repository.

TypeScript definitions ship inside the npm package at types/index.d.ts, with no separate @types install required. The package.json exports field maps plugins, languages, CSS, and interfaces as separate named exports. Node.js 14.0.0 or higher is the engine requirement.

Editorial conclusion

SunEditor fits projects that need a capable WYSIWYG editor without adding a dependency tree, and that can commit to Chrome 119 and Firefox 125 as their floor. Only a build reveals the actual bundle weight for a given plugin selection. Before integrating, read ARCHITECTURE.md for the strictMode details, because the editor rewrites HTML outside its content model and that behaviour is not explained in the README. Projects depending on IE11 support have no path forward in v3, and the v2-legacy branch deserves a close read of changes.md before treating it as frozen.

Frequently asked questions

Official sources

1. JiHong88/suneditor on GitHub
2. License: MIT
3. Project website
4. README
5. Releases