You have been dropping files on this site to read them. At some point somebody asks whether the same thing can live inside the application you work on — a case file, a claim, a drawing, opened in your own page instead of downloaded. It can, and the decision is smaller than it looks, because only one thing really changes.
The one thing that changes: where the file goes
Here, you upload a document to us, it renders, and it is deleted when you close it. That is the right trade for a file you were sent once and want to read now.
It is the wrong trade for a document that is not yours to move. A medical record, a signed contract, a drawing under NDA — those cannot leave your infrastructure, and no promise about deletion fixes that, because the file still travelled. Embedding the renderer inverts it: the document is opened by your server, inside your network, and what reaches the browser is a rendering. The file never moves.
That is the reason to embed. Everything else is detail.
It is a component, not a widget
The part people get wrong first: this is not JavaScript that opens the file in the browser. It is a native .NET component that you reference from your project, and the rendering happens server-side. Your page receives the result.
Two consequences follow. The good one: the browser installs nothing — no plugin, no ActiveX, no reader — so it works the same on a locked-down desktop as on a phone. The one to plan for: your server does the work, so a 200-page PDF and a 40 MB drawing are not the same request. Size the machine for the biggest file you will accept, and refuse anything larger at the upload.
What you have to decide before you start
Three questions, and none of them are about the viewer:
- Where do documents come in from — a database, a file share, blob storage?
- Who is allowed to see this one, and does the viewer's URL enforce that or just assume it? A rendering endpoint that answers to anyone with the document id is the classic hole.
- What happens to the temporary files the render produces, and when.
Answer those and the integration itself is short. Leave them for later and you will be retrofitting authorisation onto a viewer that already works, which is worse.
Where it runs
.NET Framework 4.0 and above, and .NET Standard 2.0 and above — so WebForms, MVC, ASP.NET Core, Blazor Server and Linux containers. Office does not need to be installed on the server; the renderer reads the formats directly.
If you only wanted to read one file today, that is what the PDF viewer and the rest of the viewers here are for. If it is the application you are thinking about, the component, its packages and its API documentation are at Doconut.com.