Pick the shape of your problem
Doconut is one SDK, but the reason teams reach for it differs. Some arrive with a framework constraint — it has to work in Blazor, it has to sit in an existing ASP.NET Core pipeline. Others arrive with a format problem — nobody on the team wants to own a DOCX renderer. Start from whichever describes you.
By framework
You already know which stack it has to live in.
Blazor
A document viewer that behaves inside Blazor
Server-side rendering with a widget that mounts cleanly into the Blazor interop lifecycle — Server and WebAssembly both supported.
BlazorASP.NET Core
Three middleware calls, not a rewrite
Registers as ordinary DI plus middleware. Inherits the authentication, logging and hosting you already have.
ASP.NET CoreBy format
You already know which files have to open.
A PDF viewer that does not hand over the PDF
Server-side PDF rendering into page images — the user reads the document without ever receiving the file.
PDFWord
Word documents without Word on the server
Native DOC/DOCX/RTF/ODT rendering with no Office install, no COM interop and no server-side automation.
WordExcel
Spreadsheets your users can read but not mine
Server-side rendering of XLS/XLSX/ODS/CSV with formatting preserved and hidden sheets left behind.
ExcelArchived email that opens without Outlook
Renders Outlook MSG, EML and EMLX server-side — readable archived correspondence with no mail client installed.
EmailNot sure which one fits?
The viewer is the same in every case — the differences are integration details. Request evaluation access and try it against your own files.