WPF HTML Editor Control

Your ViewModels should not care that HTML is involved. BodyHtml, DocumentHtml, and DocumentTitle are real dependency properties that bind two-way by default: BodyHtml="{Binding Draft.Body}" loads the document from your ViewModel and flows edits back as the user types, with UpdateSourceTrigger under your control. The editor drops into an MVVM codebase the way a TextBox does.

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.

Much of the HTML inside business apps now starts as an AI draft - support replies, CRM messages, templates. The editor is the review surface where a person refines that draft before it ships: load AI output through BodyHtml, let users edit it visually, and let the Pasting event and clean-HTML pipeline keep machine-generated markup within your rules.

Most of an evaluation is spent teaching an assistant an API it has never seen, then deleting the code it invented. SpiceLogic publishes an official Model Context Protocol server for this control, among the first from a .NET UI vendor, so Claude Code, Cursor, and VS Code Copilot read the real signatures, the real documentation pages, and snippets that compile today.

Connect it once with claude mcp add --transport http spicelogic-wpf-editor https://mcp.spicelogic.com/html-editor/wpf, then describe what you want built and let the assistant write it. The endpoint is scoped to WPF, so a WPF question can never be answered with WinForms's API.

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. Content.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

WPF buyers notice when a third-party toolbar looks blurry beside the rest of the application. Every toolbar icon is a XAML vector path, not a PNG - crisp at 100%, 150%, and 200% scaling, on 4K monitors and per-monitor DPI setups, with Options.ToolbarIconSize offering small, medium, and large sets. The toolbar lives visually inside your WPF application instead of looking like an older component pasted on top.

The editor uses standard WPF theming: swap a ResourceDictionary and it follows your light mode, dark mode, or corporate design system - no proprietary skin engine, no separate theme format to learn. For teams that need to retemplate end to end, the Source Code License includes the full control source.

In a real application Ctrl+S, Ctrl+F, and Ctrl+P already mean something. KeyBindings binds, remaps, disables, or overrides any of 35 editor actions 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 XAML 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, YouTube, style-builder, and spell-check dialogs are real WPF windows that 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; the right-click menu is yours too via EditorContextMenuStrip.

Toolbar, tooltips, dialogs, and context menus ship localized in 14 languages - German, French, Spanish, Italian, Dutch, Portuguese, Polish, Czech, Swedish, Danish, Norwegian, and both English variants - one Language property switches everything. Spell-check language is configured separately through SpellCheckOptions.SpellCheckLanguage, 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 Windows Forms instead? A separate WinForms 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.