Quill 2 from a CDN, and a repository that last moved in July 2025

One library, two themes, and a core build that is not an editor

The CDN section offers three scripts and three stylesheets, and the difference between them decides what you have to build. quill.js is the whole editor. quill.core.css and quill.core.js are described in the README as the core build with no theme, no formatting and no non-essential modules, which is a document model and a parser without an editing surface. The two theme stylesheets are quill.snow.css and quill.bubble.css, the first a fixed toolbar, the second the tooltip style that appears on selection. Consequence: copying the core snippet on its own gets you a container that can hold content and cannot format or show a toolbar, and the README gives no third option for assembling the missing parts. The theme link and the full library are what the quickstart pairs together, which is the combination to start from unless you have a reason to skip the toolbar.

The toolbar is wired by class name, not by JavaScript

There is no JavaScript in the quickstart's toolbar. Buttons are declared in a container with the id toolbar, and the format comes from a class on the button:

<!-- Create the toolbar container -->
<div id="toolbar">
  <button class="ql-bold">Bold</button>
  <button class="ql-italic">Italic</button>
</div>

Two things follow from that design. Adding a format is a markup change, so a toolbar is reviewable in a diff the way application code is. And format availability is decided by two places at once: the build you loaded, which is where the formatting modules live, and the classes you put in the container. The README snippet stops mid-line at the script that creates the editor object, so the options object that binds the toolbar to the div is not visible in the repository README. That binding, and the full list of format classes, live in the quickstart at quilljs.com/docs/quickstart, which you need open next to the markup above.

The editor starts from whatever HTML you leave in the container

The container is seeded before the library loads, and that seed is the initial document:

<!-- Create the editor container -->
<div id="editor">
  <p>Hello World!</p>
  <p>Some initial <strong>bold</strong> text</p>
  <p><br /></p>
</div>

Plain paragraphs and a strong tag are what the example uses, and the trailing empty paragraph is there so the caret has somewhere to land. This is the part of the setup that deserves a decision rather than a copy: if you render the container from stored content or from anything a user typed into a textarea, the conversion of that HTML into the editor's internal document is where formatting gets lost. The README does not document which tags survive that conversion, and it does not say what happens to attributes such as class or style. The quickstart and the guides on quilljs.com are the only sources here for the accepted input, so read them before you wire saved content into that div.

Every CDN URL pins the major, not the patch

Each script and link in the README carries the same versioned path, and the version is the major alone:

<!-- Include the Quill library -->
<script src="https://cdn.jsdelivr.net/npm/quill@2/dist/quill.js"></script>

That single choice has a consequence for anything you ship. A major-range tag resolves to whatever 2.x the registry holds at request time, so a page that passed testing on 2.0.3 can load different bytes tomorrow without a deploy on your side. For applications, the package route gives you a lockfile to hold the patch level:

npm install quill

The published version is 2.0.3, which is also the version recorded in the repository's root package.json, so the number to record in your own lockfile is a patch tag rather than quill@2. If you keep the CDN for simplicity, decide now whether an unannounced minor upgrade is acceptable in your page, because that is what the tag permits.

A monorepo where the website builds against the local editor

The checkout is an npm workspace, not a single package. The root is private, named quill-monorepo, holds workspaces at packages/*, and every script delegates into a workspace: build runs build:quill and build:website together, lint runs across all workspaces. Two details matter to anyone contributing. The start script for the website sets NEXT_PUBLIC_LOCAL_QUILL=true, so the docs site can be pointed at the editor build on your machine instead of the published package. And the fixed ports are declared in the root config, 9080 for the webpack dev server and 9000 for the website, so a second checkout on the same machine collides with the first. The engine requirement is npm 8.2.3 or newer with engineStrict set, and the presence of package-lock.json means npm is the supported toolchain rather than pnpm or yarn.

No commit since 2025-07-25 and no docs directory in the tree

The repository's last push to main was on 2025-07-25. The newest release is version 2.0.3, tagged on 2024-11-30, preceded by 2.0.2 on 2024-05-13 and 2.0.1 on 2024-05-01. Read together, those dates mean the published package and the branch have been sitting still for over a year, and the gap between the two releases in September was three weeks while the gap since then is measured in months. Slab is the company behind the project, with Jason Chen and Byron Milligan credited as its creators, and support runs through GitHub issues and discussions. What you do not get from the repository: the root holds no docs directory, since the documentation is the separate site at quilljs.com, and there is no SECURITY.md alongside the CHANGELOG.md and the BSD 3-clause LICENSE. Consequence for an adopter: browser regressions and dependency advisories become your problem to fix, and the version of the documentation you read is not pinned to the version in your node_modules.

Where Quill differs from TipTap

The comparison that comes up most often on this project is TipTap, and the two differ in where the work sits. Quill ships the editing interface with the library: a toolbar container, two finished themes and format classes you put in your own markup, so a standard editor is a copy of the quickstart. TipTap is built the other way round, as a headless editor where the document model and its schema are the library and the surrounding interface is assembled from extensions you choose, which leaves the toolbar, menus and placeholder behaviour to you. Neither approach is free. With Quill, a product that needs an editing surface unlike a fixed toolbar plus tooltip has to work against the theme and the format model it already has. With TipTap, that surface is where the project effort goes. The decision turns on whether the editor chrome is a solved problem for you or part of what you are building.

Editorial conclusion

Adopt Quill when you want a conventional toolbar editor without assembling a document model or a UI layer yourself, and pin the exact version instead of the major tag, because quill@2 in a CDN URL resolves to whatever 2.x is current. Do not adopt it expecting an upstream that patches browsers, ships security fixes or refreshes the docs for you. Before the first commit, check two things: that the version in your node_modules matches the quilljs.com quickstart you are copying from, since the documentation lives on a separate site with no directory in the repository, and that the last release, 2.0.3 from 2024-11-30, is recent enough for the browsers you support.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes