.NET WinForms HTML Editor Control

A business app rarely stores HTML for only one destination. One screen may save a fragment into a SQL column. Another may generate a complete document for email, export, or preview. The editor gives you both output shapes without making you scrape the DOM yourself.

• BodyHtml: the inner HTML of the document body, useful when you store content inside your own page, template, or database field.
• DocumentHtml: the full HTML document, including document wrapper and header information, useful when you save or send standalone HTML.

HTML5 is the default document type, with override controls available for older render targets. That keeps the output practical for real WinForms systems where content may move between templates, email bodies, helpdesk notes, and reporting workflows.

Your users will paste from Word and Outlook. That is not a maybe. The real question is whether your editor leaves you with usable HTML or a pile of Microsoft Office clipboard noise.

The editor auto-detects Microsoft Word and Outlook clipboard content and cleans the pasted HTML automatically. Users do not need to remember a special "Paste from Word" button, and developers are not left chasing MsoNormal markup through saved templates, email bodies, and support replies.

This is one of the places where a do-it-yourself editor usually looks cheap at first and expensive later. Clipboard HTML is not just text. If your application needs stricter rules, the Pasting event gives you a checkpoint before clipboard content enters the document.

Real users do not only type paragraphs. They paste screenshots into tickets, add product images to templates, and insert logos into email bodies. The editor supports images from a local file, an absolute URL, or directly from the clipboard.

Depending on your configuration, local images can be referenced by path or embedded as Base64 so the HTML becomes self-contained. Large pasted images can be resized automatically with MaxPastedImageWidth, so one oversized screenshot does not destroy the layout of an email, ticket, or knowledge-base article.

When you need portable output, EmbedLocalImagesAsBase64() can walk the document and convert local images into Base64 Data URIs. That is the kind of plumbing developers usually discover only after the first support screenshot breaks the design.

Spell check should not become another deployment project. There are no native DLLs to copy and no dictionary files to ship for the built-in languages because 14 Hunspell dictionaries are embedded directly in the control. Pick a language and the dictionary is already there.

Set SpellCheckOptions.SpellCheckLanguage to English (US), English (GB), German, French, Spanish, Italian, Dutch, Danish, Swedish, Norwegian, Polish, Czech, Portuguese (Brazil), or Portuguese (Portugal). Or leave it on Same as Editor Language and it follows the editor UI language automatically.

The engine is a pure-managed Hunspell implementation. Inline red-squiggle checking, dialog-based checking, and a per-user custom dictionary are supported. Need another language? Point it at any OpenOffice .dic / .aff pair. Already have your own spelling engine? Plug it in through ISpellCheckerEngine.

For international desktop software, the editor itself cannot stay English-only. Use EditorLanguage to localize toolbar text, tooltips, dialogs, and context menus so the editor does not feel like a foreign component dropped into an otherwise localized application.

Supported language packs include German, Dutch, French, Spanish, Italian, Polish, Portuguese for Brazil and Portugal, Norwegian, Czech, Swedish, and Danish.

Spell-check language can be configured separately, so the application UI and the content language do not have to be the same. That matters for European and multinational teams where the application shell, editor chrome, and authored content may each follow different language rules.

A third-party editor should not look like a separate island bolted onto your form. Use the built-in toolbar as-is, remove commands your users should not see, replace button behavior, or build your own toolbar around the editor services.

ToolbarItemOverrider lets you intercept built-in toolbar actions. The StateQuery service lets your UI know whether the current selection is bold, italic, inside a table, undoable, redoable, and more.

That means your Save button can call your save pipeline, your ribbon can drive editor actions, and your application can hide features that do not belong in a regulated, simplified, or role-specific screen. You get a working toolbar without surrendering your product's UX.

An embedded editor should not fight the host application for keyboard shortcuts. In a real WinForms app, Ctrl-S, Ctrl-F, Ctrl-P, undo, redo, paste, and formatting shortcuts may already have application-level meaning.

The KeyBindingsManager exposes binding, unbinding, overriding, disabling, enabling, and querying for editor actions represented by EditorActionId. Use it to align the editor with your application's shortcut conventions for bold, italic, cut, copy, paste, undo, print, search, spell check, list commands, alignment commands, insert commands, and other editor actions.

Keep familiar editing shortcuts where users expect them, or let your host application's global commands win when the editor has focus. Either way, the keyboard model stays under your control.

Generic editor dialogs are fine for a sample project. They are harder to ship inside a branded ISV product, a regulated desktop app, or a workflow where your image picker, hyperlink rules, table defaults, and search behavior already have business logic.

You are not locked into the default dialogs. The source code for the editor dialogs is provided so you can study, brand, customize, or replace them. Replacement interfaces include IImageDialog, IHyperlinkDialog, ISearchDialog, IStyleBuilderDialog, ISymbolDialog, ITableDialog, ITableCellDialog, IYouTubeVideoInsertDialog, and ISpellCheckerDialog.

You can also provide your own ContextMenuStrip through EditorContextMenuStrip, so right-click behavior can match the rest of your application.

Tables are where many simple HTML editors start to fall apart. Users insert a table, edit a few cells, then the next dialog open no longer understands what is already there. The result is usually delete-and-redo, which users hate and support teams hear about.

The two-way table dialog is designed to read the existing table structure and styling back from the document, so users can continue editing rows, columns, borders, cell styling, and structure without starting over.

For code-driven workflows, Content.TableAuthoringService exposes table operations such as InsertRow, InsertColumn, and MergeSelectedCells. You get visual table editing for users and programmable table operations for your own commands.

Not every user who needs formatting should be asked to write CSS. The visual style builder gives users a dialog-driven way to adjust common formatting choices such as fonts, colors, borders, background, and spacing.

That is useful in line-of-business software where users need more control than plain rich text, but you do not want them editing raw markup just to make a template or support article readable.

Developers can use the style builder at design time or runtime. Advanced teams can extend it with custom pages using IEditorStylePage and FormSelectorPageAttribute, so your own styling rules can sit beside the built-in formatting controls instead of living in a separate workaround screen.

Paste is one of the most underestimated features in a business editor. Users paste from Word, Outlook, browsers, spreadsheets, screenshots, and internal tools. Without a policy, saved HTML becomes a mix of unknown tags, unexpected links, huge images, and support problems.

The Pasting event gives your application a checkpoint before clipboard content becomes part of the document.

Use it to clean HTML, strip unwanted tags, block oversized content, rewrite image references, reject external links, or apply your own business rules before the editor accepts the paste. This matters in real enterprise apps, where "just let users paste anything" eventually becomes a support, security, or data-quality problem.

Many business editors are not free-form text boxes. They are template builders. Users need to insert fields like customer name, invoice number, due date, ticket ID, assigned agent, or company name without typing fragile tokens by hand.

The mail-merge placeholder API lets your application define the available fields and expose placeholder insertion through the editor workflow. Users insert placeholders at the caret, and your application replaces them later when generating the final message or document.

This is useful for email templates, CRM messages, invoice notes, notification bodies, support replies, and document templates. It turns the editor from a formatting surface into a practical template authoring tool for line-of-business workflows.

The editor is not only a visual surface. It exposes the services senior developers need when the control becomes part of a real product instead of a demo form.

• Content service. Read, set, insert, transform, and export HTML through the Content service.
• Caret service. Get and set caret position by point or index through the Caret service.
• Editor commands. Cut, copy, paste, undo, redo, search, replace, print, print preview, and command execution through the Editor service.
• Formatting service. Apply bold, italic, underline, font, colors, alignment, lists, headings, and format removal through Formatting.
• Selection service. Read selected HTML, select text, select all, trim selections, and inspect selection data through Selection.
• State query service. Ask whether the current selection is bold, italic, inside a table, undoable, redoable, and more through StateQuery.
• Change tracking. Use HtmlChanged to drive dirty flags, save prompts, and live previews.
• Email-ready output. Use GetEmailMessageWithLocalImagesEmbedded() when you need a mail-ready message with local images embedded.

Building a WPF application instead of Windows Forms? We also offer a separate WPF HTML Editor Control with its own landing page, documentation, and licensing.

Use this page for WinForms applications. Use the WPF product page when your application is built on WPF.

That separation is deliberate. A WinForms team should not be forced through a WPF story, and a WPF team should not be told to settle for a WinForms-shaped integration. Pick the control that matches your desktop UI stack, then test the trial in the application you actually ship.