EnterraHost
A JavaScript rich text editor that you add to a page with one script tag and no build step. EnterraEdit is a drop-in replacement for a plain textarea, so the form you already have keeps posting the field it always posted.
Every route to it is free and the license is MIT. There is no key to obtain, no account, and nothing to sign up for. The product page has a live demo, and this guide is what the editor is and what it is not.
Why this JavaScript rich text editor is different
Two layers, and the distinction explains most of its behavior. Underneath is a real ProseMirror document model, which is where the schema, the selection handling and the undo history come from. On top is a declarative layer that finds your textarea and upgrades it.
That second layer is the whole point. A framework editor expects you to build a page around it. This one expects to find a field that already exists.
The two lines that integrate it
One script tag in the head, and a data-enterraedit attribute on a textarea. That is the entire integration, and either attribute can be on the script or the field.
The textarea stays in the DOM and stays in sync with the editor, which is the detail that makes it drop-in. Your existing form posts the same field name it always did, so nothing on the server changes. If you remove the script, the page falls back to a working textarea rather than an empty box.
Three ways to get it, and the one difference between them
From the CDN. One script tag pointing at cdn.enterrahost.com, and nothing to build or update. This build carries a small attribution badge in the corner, and that badge is what pays for the CDN. The other two routes do not have it.
From npm, if you would rather bundle it into your own build rather than load a script at runtime.
From source, which produces a fully badge-free build and is the route for anyone who will not load a third-party script at all. The repository is public at github.com/enterrahost/enterraedit and you can read every line before you build it.
The three do not differ in capability. The badge is the only difference, and it is worth knowing which you are running before you compare what you see with what a guide describes. The CDN route is covered on its own, and the self-hosted route is next.
What it does not bring with it
One file, and nothing else arrives with it. No fonts, no icon sets, no analytics, and no network requests at runtime. The icons are drawn rather than loaded, so there is no icon font to fetch and no flash of unstyled glyphs on first paint.
For an editor that matters, because the alternative is a component that looks broken for the first second on a slow connection.
What it is built on
ProseMirror, by Marijn Haverbeke and contributors, which is also MIT. It is compiled into the built file rather than loaded alongside it, so the copyright notice is prepended to the distributed script and the full text is in THIRD-PARTY.md.
That is the only third-party code in the build. If you are auditing what a script is allowed to do on your page, the answer is that this one makes no runtime requests at all, which is a shorter conversation than most script tags allow.
What is not there
Four things are missing or rough, and they are worth knowing before you choose it rather than after.
File upload is not implemented. An image can be pasted, dropped, embedded as a data URI or referenced by a URL, which suits a field posted with a form. A real attachment workflow needs a server endpoint to receive the file, and that is out of scope for a drop-in editor.
There is no attachment node for non-image files. That is deliberate. Restricting file types cannot be done from the browser, so a control offering to do it would imply a guarantee the editor cannot make.
There is no explicit paste-as-plain-text shortcut. Pasting from Word, Google Docs or a web page arrives clean anyway, because the schema drops what it does not model. Font tags, inline styles, class attributes and Office properties all disappear, and scripts never arrive at all. What is missing is a deliberate way to strip the markup while keeping the structure.
The accessibility work is asserted rather than experienced. Every button has an accessible name, the toolbar follows the ARIA pattern, and the tests check all of it. Nobody has yet driven it with a screen reader end to end, and structural correctness is not the same claim as usability. That is stated plainly rather than left for somebody to discover.
Where to go next
If you want the fastest integration, that is the CDN. If you would rather ship no third-party script, that is self-hosting. If you want to change how it looks, the accent color, the toolbar and the theme are one configuration object rather than three separate jobs.