DOCX Viewer in ASP.NET Core: Preview Word Files

To preview a Word document inside an ASP.NET Core application, use a DOCX viewer SDK that renders the file on the server and displays its pages in the browser. Doconut provides this workflow without requiring Microsoft Word on the server. Your users can read a contract, proposal, or report inside your application instead of opening a separate desktop program.

The useful question is what happens when you replace the demo file with your own documents. A contract may contain custom fonts, repeating headers, wide tables, and signature pages. This guide shows the document-opening step for a .NET 8 application and the checks that help you evaluate the result.

Open a DOCX file from C#

Start with the Doconut .NET 8 quick start to configure the services, ASP.NET session, document middleware, viewer resources, and browser widget. The following endpoint extends that configured application; it is not a complete standalone application.

Place a non-sensitive test document at App_Data/Sample.docx beneath the application's content root. Add this endpoint before app.Run():

using Doconut;

app.MapPost("/api/preview-word", async (
    Viewer viewer,
    IWebHostEnvironment environment) =>
{
    var filePath = Path.Combine(
        environment.ContentRootPath, "App_Data", "Sample.docx");

    if (!File.Exists(filePath))
        return Results.NotFound();

    var token = await viewer.OpenDocumentAsync(filePath);
    return Results.Ok(new { token });
});

Keep the using directive with the other imports at the top of Program.cs. The fixed path makes the example easy to reproduce and avoids accepting an arbitrary server path from the browser.

The Viewer API reference documents the file-path overload of OpenDocumentAsync. It opens the file and returns a document session token. On the page where the quick start has already initialized objViewer, open the preview with:

async function previewWordDocument() {
    const response = await fetch('/api/preview-word', {
        method: 'POST'
    });

    if (!response.ok) {
        throw new Error('The Word preview could not be opened.');
    }

    const { token } = await response.json();
    objViewer.View(token);
}

Call this function from your page's preview action and display any error through the application's existing error UI. Keep the request on the same application origin as the viewer in this example.

Keep document access under application control

In a customer portal, replace the fixed sample with a document record selected by your application. Check that the current user may view that record before resolving its storage location and opening it. A filename received from the browser is not an authorization decision.

Store protected originals outside the public web root. The example's App_Data folder is a storage convention, not an access-control feature: do not expose it through a static-file mapping. Keep authentication and document permissions in the host application.

The browser receives a viewing token for the document session. Treat that token as a credential rather than a permanent document URL. The quick start also covers closing a document when the reader leaves or opens another file.

Test Word layout with representative files

An empty DOCX proves little about the documents your customers use. Build a small evaluation set from the actual templates your application needs to display, with sensitive information removed.

Test document	What to inspect in the preview
Contract with headers and footers	Repeated content, page numbers, and signature-page placement
Proposal using a corporate font	Font substitution, line wrapping, and heading widths
Report with wide or nested tables	Column widths, row splitting, and text clipped at page boundaries
Document mixing portrait and landscape sections	Page dimensions and the transition between sections
Image-heavy manual	Image placement, captions, and readability when zoomed

Compare the rendered result with the approved source document. Decide which differences matter to your workflow before committing to the integration.

Doconut exposes Word-specific rendering settings through WordConfig. The format configuration reference includes FontFolders for additional font directories, paper-size settings, and AutoFitAllTables for table fitting. Change these deliberately: making a table fit the available width can also change the layout you are trying to preserve.

Repeat the checks on the deployment host. A preview that uses a font installed on a developer's machine can look different when that font is absent from the server. Use fonts your organization is permitted to deploy.

Choose viewing, editing, and conversion separately

A DOCX preview solves the reading step. It does not turn your application into a Word authoring environment.

• Reading: use the viewer when someone needs to inspect an existing document inside a case, order, or customer record.
• Editing: if users must rewrite paragraphs and save an updated DOCX, evaluate an editing workflow separately. Previewing a file is not evidence of Word editing support.
• Conversion: if the requirement is a downloadable file in another format, assess that export workflow separately from displaying pages.

The Word viewer for .NET overview describes Doconut's Word-family viewing path. Use it to check the product fit, then use your own files to assess the rendering behavior that matters to your application.

Evaluate the viewer with your hardest document first

Begin with a document that already causes support requests: a long contract, a table-heavy report, or a template with unusual fonts. Check the preview, navigate several pages, reopen it in a fresh session, and verify that the surrounding application enforces the correct document permissions.

Download Doconut and run the .NET 8 sample with that file. A successful evaluation should demonstrate that users can read the documents they actually receive, with a layout your team has reviewed and an integration your application can maintain.