EnterraHost
The fastest way to get a rich text editor CDN build onto a page is one script tag and one attribute. Nothing is installed, nothing is bundled, and there is no build step between you and a working editor.
It is the route to pick when you want the editor running in the next five minutes and you are happy to load a script from somewhere else. One thing is different about it, and it is the badge described below. Knowing that before you start saves comparing your result against a guide written for a different build.
The script tag
One line in the head, and the version is part of the path rather than floating. That matters, because /v1/ stays on version one when a breaking change lands and a new major appears beside it. A URL with no version in it silently upgrades, and an editor that changes under a live site is not a dependency anybody asked for.
<script src="https://cdn.enterrahost.com/enterraedit/v1/enterraedit.min.js"></script>There is nothing to build and nothing to keep up to date. When a new minor version ships, you get it without touching the page.
Putting it on a field that already exists
The editor looks for a textarea carrying the data-enterraedit attribute, or a page where the script tag itself carries it. Either works, and the attribute is the whole configuration for the default case.
<textarea name="body" data-enterraedit>
<p>Anything you like.</p>
</textarea>The textarea stays in the DOM and stays in sync with what the editor shows, so your form posts the field it always posted and no server code changes. If the script fails to load, the page falls back to a plain working textarea rather than an empty box, which is the difference between a degraded page and a broken one.
The badge, and why it is there
The CDN build draws a small attribution badge in the corner of the editor. It is what pays for the CDN, and it is free to use precisely because of it. The live demo shows exactly what it looks like in place.
Two details make it less annoying than it sounds. It is hidden on narrow screens, so a phone at 420 pixels or less never sees it and the toolbar gets the space instead. And it is the only difference between this build and the self-hosted one, so nothing you read about the editor elsewhere stops applying.
If the badge is the reason you are hesitating, the honest answer is that self-hosting removes it and costs you a build step instead.
What the page fetches
The script, and then nothing. No fonts, no icon set, no analytics, and no request at runtime. The 32 icons are inline SVG drawn from the same file rather than a webfont, and the styles are injected by the script rather than linked. The source is public if you would rather check that than take it on trust.
That is worth more than it looks. An editor that loads an icon font shows a row of empty boxes until the font lands, and on a slow connection that is the first thing a visitor sees. It also means the editor keeps working when the connection drops mid-session rather than losing its icons.
This is the only third-party request the page makes, which is a shorter conversation than most script tags allow if you are auditing what a page is allowed to load.
Sizing it without JavaScript
The declarative attributes cover the common cases, so the drop-in route never needs a script block of its own.
<textarea data-enterraedit></textarea> <!-- fills the container -->
<textarea data-enterraedit data-width="420px"></textarea>
<textarea data-enterraedit data-height="auto"></textarea>
<textarea data-enterraedit data-rows="6"></textarea>An unset width fills the container, which is usually what you want. Sizes are applied as custom properties rather than inline dimensions, so a stylesheet can still override them and the editor stays fixable on a small screen. Width uses inline-size, which means it mirrors correctly in a right-to-left layout without a second rule.
When a rich text editor CDN is the wrong choice
Three cases, and they are worth knowing before you commit to it.
You cannot load third-party scripts. A strict content security policy with a short allow list, or an internal rule against external script origins, rules this route out entirely. The editor can run under a strict policy, but the script has to be served from your own origin for that to be possible.
The badge is not acceptable. It is small and it hides on phones, and it is still visible on a desktop.
The page has to work with no network at all. An intranet, a kiosk or an offline application needs the file on disk. Loading it from a CDN is the thing you cannot do.
In all three cases the answer is the same, which is to bundle or serve the file yourself. The integration is identical, so nothing else in this guide changes.
If you would rather change how it looks before you pick a route, the accent color, the toolbar and the theme are one configuration object and work the same either way.