Summernote: a jQuery WYSIWYG editor you drop into a div

What Summernote solves, and which pages it fits

The problem is mundane and recurring: a form needs a textarea that produces formatted HTML, and the team does not want to build a toolbar, a dialog system and a paste handler from scratch. Summernote is a JavaScript library that creates that editor inside an existing element. The README frames the appeal as a simple interface, install by including JS and CSS files, compatibility with Bootstrap 3, 4 and 5, a plugin and connector ecosystem, and image handling that embeds images as base64 so no separate image store is needed.

The audience is therefore specific. It is a team with a server-rendered page, jQuery already loaded, and a Bootstrap layout. The repository ships separate example files for Bootstrap 3, 4 and 5, which tells you the maintainers treat the Bootstrap version as a first-class choice rather than an afterthought. The npm package declares that it is built on jQuery, and the README repeats that dependency in the usage section. If your page has no jQuery and no intention of adding it, the cost of adoption is not one script tag, it is a second DOM library in the bundle.

That base64 image behaviour is the design decision worth pausing on. It removes an upload endpoint and a storage bucket from the critical path, which is genuinely convenient for a small CMS or an internal tool. It also means the submitted HTML carries the image bytes inline, so a few screenshots can turn a modest post into megabytes of markup. The README presents this as a feature, and for small deployments it is. For anything with many images or a size budget, it is a constraint you will meet later.

How the editor is wired: div, jQuery plugin, code API

The mechanism is deliberately thin. You place a div in the body, call the summernote function on it through jQuery, and the library replaces that element with its own editor markup. The README describes the div as the element that will be replaced. There is no virtual DOM, no build step required for the consumer, and no component lifecycle to learn.

State travels in and out through the same API surface. The README's example reads the underlying HTML with a string argument:

var html = $('#summernote').summernote('code');

That single call is the contract most integrations depend on: the editor owns the DOM while the user types, and you ask for the HTML when you need to persist it. Around that core, the repository's examples directory shows the extension points the project actually supports, including air mode, a CodeMirror integration, external API control, custom events, language files, a placeholder option, history limits and several hint providers for emoji, math and user-defined words. Those example filenames are the most honest map of the feature set, because the README itself stops at the basic API and points to the website for the rest.

The architecture also explains the project's sharpest warning. The code view lets a user type script contents directly, and the README instructs you to filter or sanitize the HTML on the server. Summernote is a browser-side editor; it has no server component and no opinion about what you do with the string it hands back. Any trust boundary you need lives in your own backend.

Installing Summernote and getting a first editor on the page

The README's install path is three steps. First, include jQuery, a Bootstrap stylesheet and bundle, then the Summernote CSS and JS for your Bootstrap version. The snippet below is the Bootstrap 5 variant as the README gives it, with the file names summernote-bs5.css and summernote-bs5.js. If you are on Bootstrap 3 or 4, the examples directory has summernote-bs3.html and summernote-bs4.html showing the matching assets.

<script type="text/javascript" src="//code.jquery.com/jquery-3.6.0.min.js"></script>
<link rel="stylesheet" href="//cdn.jsdelivr.net/npm/[email protected]/dist/css/bootstrap.min.css" />
<script type="text/javascript" src="//cdn.jsdelivr.net/npm/[email protected]/dist/js/bootstrap.bundle.min.js"></script>
<link href="summernote-bs5.css" rel="stylesheet">
<script src="summernote-bs5.js"></script>

Second, put a div where the editor should appear. The README's example uses the id summernote and the text Hello Summernote, which is what the user sees before initialization.

<div id="summernote">Hello Summernote</div>

Third, initialize it once the document is ready. After this runs, the div is gone and the toolbar is in its place.

$(document).ready(function() {
  $('#summernote').summernote();
});

To read the result back, call the code command shown earlier and send the returned string to your server. The package is also published on npm under the name summernote, with main pointing at dist/summernote.js, so a bundler-based setup can import the distribution instead of using the CDN files. Note that the package declares type module and engines node >=17.0.0, so the toolchain around a source build is modern even though the runtime dependency is old-fashioned jQuery.

The sanitization warning is the real limitation

The README carries an explicit warning about code injection: the code view allows the user to enter script contents, and you must filter or sanitize the HTML on the server, otherwise an attacker can inject arbitrary JavaScript into clients. This is not a footnote. It is the boundary of what the library does. Summernote gives you a rich editing surface and a string; it does not give you a safe string.

That shapes where Summernote is the wrong tool. If your architecture cannot run a server-side sanitizer on the submitted HTML, or if the HTML is rendered back into other users' browsers without passing through one, the editor's convenience becomes a stored cross-site scripting path. The same applies to the base64 image behaviour: the payload arrives inside the HTML you are about to store, so any size or content validation has to happen after submission, not at an upload endpoint.

There is a second, quieter cost. The project depends on jQuery, and the README states it plainly. Teams that have spent effort removing jQuery from a frontend will be adding it back for one form. That is a legitimate trade for a server-rendered admin page and a poor one for a modern single-page application. The repository's own examples show the integrations the project invests in, and a framework-native component is not among them; Angular, React and Django users rely on third-party wrappers rather than anything in this repository.

Maintenance is worth stating as a fact rather than an impression. The last push to the repository was on 2026-04-15. The most recent release is v0.9.1 from 2024-10-09, preceded by v0.9.0 on 2024-09-28 and v0.8.20 back on 2021-10-14. The gap between 0.8.20 and 0.9.0 is roughly three years, so releases arrive in bursts rather than on a cadence. The repository is not archived, and the README says it is maintained by the community and asks for sponsors and backers, which is a candid signal about how the work is funded.

Summernote against Quill, TinyMCE and CKEditor

The honest comparison is about integration model, not feature checklists. Summernote is a jQuery plugin that replaces a div and hands you an HTML string. Quill is built around its own document model and Delta format, so the content is structured data that you render, not markup that you store. That difference decides most choices: if downstream systems consume HTML, Summernote's output drops in; if you want to control rendering and avoid storing arbitrary markup, a model-based editor fits better.

TinyMCE and CKEditor sit at the commercial end of the same category. They ship larger feature sets and, in their paid tiers, support arrangements that a volunteer-maintained project does not offer. The trade is licence and cost against the freedom of MIT terms. Summernote's MIT licence means you can use it commercially without a subscription, and the README states the licence directly. What you give up is a vendor to escalate to. The README's contact section points to a Discord community, and the contribution guide lives in .github/CONTRIBUTING.md, which is the support model in full.

For a Bootstrap admin form where the output is HTML stored in a database column, Summernote's approach is the shortest path. For a product where the editor is a core surface, where you need a defined document schema, or where you cannot guarantee server-side sanitization, the alternatives above are not sidegrades, they are different architectures.

Licence, upgrades and what a version bump costs

Summernote is MIT licensed, stated in the README and in the license field of package.json. For most teams that means commercial use without a fee, provided the copyright notice and permission notice are preserved. That is the extent of what can be said here; specific obligations depend on how you distribute the software and are a question for your own counsel, not for this article.

Upgrade cost is where the release history matters. The jump from v0.8.20 in 2021 to v0.9.0 in 2024, followed by v0.9.1 about two weeks later, is the kind of gap that makes a changelog read essential rather than optional. The repository carries a CHANGES.md at the top level, which is the file to read before moving a pinned version. The package also declares type module and engines node >=17.0.0, so a build from source assumes a reasonably current Node toolchain even though the browser-side library is plain jQuery.

Because the library is distributed as static CSS and JS files, the upgrade itself is usually a file swap plus a check of the Bootstrap variant you are loading. The risk sits in the plugin and connector ecosystem referenced from the README, since third-party plugins track the core at their own pace. If your editor depends on one, verify it against the version you are moving to before you change the script tag.

Editorial conclusion

Summernote suits teams with server-rendered HTML, jQuery already on the page, and a Bootstrap layout, since the whole integration is a stylesheet, a script and one initialization call. It is the wrong tool if you need a framework-native component with typed props, or if you cannot sanitize submitted HTML on the server, because the README warns that the code view accepts script contents. Before adopting, check which build matches your Bootstrap version, confirm the version of the npm package, and test the code view path against your own sanitizer.

Frequently asked questions

Official sources

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