Moving off Summernote without losing your content

Summernote is a free, MIT-licensed editor that many sites adopted years ago. It works well for short formatted text, and it is easy to drop into a Bootstrap page. Teams usually start looking for something else when the content grows: they need comments, tracked changes, tables with header rows, or a supported vendor. Moving is less risky than it sounds if you treat the stored HTML as data, not as a fixed format, and move in small steps. For the feature comparison, see the Summernote comparison.

Start with what is actually stored

Summernote saves whatever the browser produced, so the stored HTML often contains more than the toolbar ever offered: inline styles copied from pasted pages, empty paragraphs, and nested spans from older versions. Before you pick a target editor, count the tags that appear in your real documents. The counts show which features the new editor must keep and which ones are leftovers you can drop.

// Count the element types in every stored document.
const counts = new Map<string, number>();
for (const html of storedDocuments) {
  const doc = new DOMParser().parseFromString(html, "text/html");
  doc.body.querySelectorAll("*").forEach((el) => {
    const tag = el.tagName.toLowerCase();
    counts.set(tag, (counts.get(tag) ?? 0) + 1);
  });
}
console.log([...counts].sort((a, b) => b[1] - a[1]));

Pay particular attention to images. When an upload handler was never configured, Summernote embeds images as base64 data URIs. Those documents become very large, and they are slow to load in an editor that expects image URLs. Decide whether to upload those images to storage during the move, and keep a record of which documents you changed.

Map the plugins, not just the toolbar

The toolbar is the easy part. Custom Summernote plugins, popovers and event handlers hold most of the real behaviour, and a new editor does not run them. List every plugin your team wrote, what it does, and whether the new editor already covers it. For each gap, choose one of three answers: use a built-in feature, rebuild it on the new editor's API, or drop it after checking with the people who use it.

Move in stages, and keep the old HTML

1. Load a sample of real documents into the new editor on a staging page and compare the output with the original.
2. Sanitize the stored HTML before it reaches the new editor. Untrusted content from years of edits deserves the same care as new input; see stored XSS in rich text editors.
3. Run the new editor beside the old one for a fixed period, and let writers open either.
4. Keep the original HTML in a separate column or table until the new editor has run cleanly for a month. Rolling back is easy only while the old content exists.

Check the content security policy

Many Summernote installs rely on inline scripts and styles that a strict policy blocks. The new editor may need a different policy. Test the migrated page with the policy you plan to ship, not with the relaxed one from the old site. The CSP guide for rich text editors lists the settings that usually need changing.

Migration checklist

• Count the tags in real stored documents and keep only the ones your content needs.
• Move embedded base64 images to storage, and record every document you changed.
• List every custom plugin and decide: built in, rebuilt, or dropped.
• Sanitize stored HTML before it is loaded into the new editor.
• Test under the production content security policy, not a relaxed one.
• Keep the original HTML until the new editor has run cleanly for a month.

RichTextEditor is a perpetual-licence JavaScript editor — one purchase, self-hosted, no metered editor loads. Download the evaluation or see how it compares.