.NET WinForms HTML Editor Control

One screen saves a fragment into a SQL column; another sends a complete document by email. BodyHtml returns the inner body markup, DocumentHtml the full document with head and doctype - both clean, both ready to store or send, no DOM scraping.

HTML5 output is the default, with overrides available for older render targets.

Templates need fields, not fragile hand-typed tokens. The mail-merge API lets your application define placeholders - customer name, invoice number, renewal date - that users insert at the caret and your code resolves at send time. It turns the editor into a template builder for CRM messages, invoices, and notification emails.

Users paste from browsers, spreadsheets, screenshots, and internal tools - and without a policy, saved HTML slowly becomes a support problem. The Pasting event lets your application clean markup, strip tags, reject oversized content, and rewrite links before the paste lands. Your data-quality rules run first, every time.

Fourteen Hunspell dictionaries are embedded in the control - English (US and GB), German, French, Spanish, Italian, Dutch, Danish, Swedish, Norwegian, Polish, Czech, and Portuguese (Brazil and Portugal) - so there are no dictionary files to ship. Inline red squiggles, dialog checking, and a per-user custom dictionary work out of the box; any OpenOffice dictionary or your own engine plugs in through ISpellCheckerEngine.

Most simple editors lose track of a table the moment it exists - users end up deleting and starting over. The two-way table dialog reads the existing structure and styling back from the document, so rows, columns, borders, and merged cells stay editable forever. TableAuthoringService exposes the same operations to your own code.

Screenshots in tickets, logos in signatures, product shots in templates - images arrive from files, URLs, and the clipboard. Oversized pastes are resized automatically with MaxPastedImageWidth, and EmbedLocalImagesAsBase64() turns local references into portable, self-contained HTML when output leaves the machine.

Everything the toolbar does, your code can do. Focused services keep the API discoverable:

• Content - read, set, transform, and export HTML
• Formatting and Selection - apply styles and inspect what the user selected
• StateQuery - drive your own UI state: bold, undoable, inside a table
• HtmlChanged - dirty flags, save prompts, live previews
• GetEmailMessageWithLocalImagesEmbedded() - a mail-ready message in one call

In a real application Ctrl+S, Ctrl+F, and Ctrl+P already mean something. KeyBindingsManager binds, remaps, or disables any editor action by EditorActionId, so familiar editing shortcuts stay where users expect them - and your application's global commands win whenever they should.

Use the built-in toolbar as shipped, hide commands a role should not see, or add your own buttons beside the standard ones. ToolbarItemOverrider intercepts built-in actions and StateQuery keeps custom UI in sync, so the editor follows your product's rules instead of imposing its own.

The image, hyperlink, table, search, symbol, video, and spell-check dialogs all ship with source code and replacement interfaces - IImageDialog, ITableDialog, and the rest. Restyle them, wire them to your asset library, or swap in your own forms; right-click menus are yours too via EditorContextMenuStrip.

Toolbar, tooltips, dialogs, and context menus ship localized in German, French, Spanish, Italian, Dutch, Portuguese, Polish, Czech, Swedish, Danish, and Norwegian - one Language property switches everything. Spell-check language is configured separately, because the application shell and the authored content do not always match.

The visual style builder gives users dialog-driven control over fonts, colors, borders, backgrounds, and spacing - more power than plain rich text, with no raw markup in sight. Your own styling pages can sit beside the built-in ones through IEditorStylePage.

Writers stay in WYSIWYG; developers and power users switch to a formatted, indented source view or a read-only preview of the same document. What you save is markup you can actually read - which matters once content lives in templates, tickets, and mail pipelines.

Building on WPF instead? A separate WPF HTML Editor Control exists with its own landing page, documentation, and licensing. Pick the control that matches your UI stack, then test the trial in the application you actually ship.