File Previews in .NET Core Web Applications: Two Practical Approaches

The ability to preview files directly within a web application is a major enhancement to user experience. Enabling users to view uploaded documents or images without needing to download them first saves time and reduces frustration. This can be a game changer in document-heavy applications where users frequently and recursively review and upload files through the interface. 

There are many libraries, packages, software subscriptions, and external API services (you name it!) that exist to solve this problem. But when spoiled for choice, it can be difficult to decide on which kind of solution best fits your application’s needs. 

This article explores this conundrum in the context of .NET Core web applications, with a focus on their specific quirks and requirements. 

To preview most file types in a web application, applications first need to convert them into a browser-friendly format. For documents like Microsoft Word, Excel spreadsheets, and PowerPoint presentations et cetera, this typically means converting them to PDF, which thanks to Mozilla’s pdfjs can be easily rendered in the browser 

Converting any file to another type requires some kind of file processing logic. The specifications for some file formats are huge, and require significant effort to work with, so rather than reinventing the wheel, developers typically seek existing solutions that are well suited to the job, reliably maintained, and well loved by other developers in the community. 

In .NET Core applications, two common strategies for handling these conversions are: 

 Integrating NuGet packages directly into the application’s logic 

Making requests to a hosted, containerised API service 

An example of each approach is explored further below, however, it is important to remember that these are just two of the many options available. 

Approach 1: Telerik Document Processing NuGet Packages 

Telerik are a Bulgarian software company that build software tools, libraries and components for application developers. They got their start in the 2002 focusing on components for the then-recently-announced .NET framework. We’ve used Telerik's libraries here as an example of the “in process” procedural approach to document conversion, but there are other component vendors that provide similar libraries. If you have particular features you need or an existing vendor you use for components like these it is worth checking their offerings. 

Telerik’s document processing NuGet packages can be added directly into a project via the package library or private NuGet streams. These classes can be referenced and used throughout internal logic, allowing developers to call document processing methods within custom classes in their application. 

Telerik’s Document Processing Library is a great example of this approach. Available through a private NuGet feed upon purchase, it offers a comprehensive set of tools for converting, manipulating, and even creating documents from scratch. Supported file formats include DOCX, RTF, HTML, TXT, XLSX, CSV, ZIP, and PDF. 

To use Telerik, developers need to install the relevant packages and reference them within their code. Telerik Document Processing comes out-of-the-box with straightforward methods that provide the bulk of the basic functionality, and then allows the developer to build upon this, allowing flexibility to extend functionality with custom logic or by using other built-in document processing methods. 



Approach 2: Gotenberg Containerised API

Outside of the NuGet universe, there are containerised API solutions such as Gotenberg which offer a powerful alternative. Gotenberg is an open-source API that hosts robust endpoints that manage the conversion of many different file types into PDFs with ease, including but not limited to PPTX, DOCX, RTF, HTML, TXT, XLSX, and more. The full list can be found in their documentation for the various API routes. 

By running Gotenberg in a secure server environment and sending requests from the main application, developers can offload the conversion logic entirely. This decoupling simplifies maintenance and can simplify the integration process too. 

Developers also benefit from the peace of mind that comes with using a community-supported tool that many contributors actively review and improve to keep it reliable and up to date.

 

Comparison:

NuGet Packages vs Containerised API 

Below is a quick breakdown of the comparison between these two solutions: 

Both approaches are viable, each with their  own strengths and trade-offs. If developers need a more custom integration with close-to total control over the conversion logic, a commercial NuGet package like Telerik Document Processing may be the ideal choice. On the other hand, if a decoupled, open-source, low-maintenance solution with broad format support (including PowerPoint – PPTX conversions to PDF) is required, a containerised solution such as Gotenberg might just be the best solution. 

 Ultimately, the choice depends on the application's requirements, infrastructure, and development preferences. Both solutions will get the job done in different ways, and both will provide file conversions successfully to the application so it can display them on the front end. Speaking of which, what exactly does the front end integration look like? 

What about the Front End? 

Whichever backend solution you choose for file conversion, you'll also need a front end component to display those files to users on the UI (User interface). 

HTML (Hypertext Markup Language) which is a language that is used to build the structure of a web page, provides native support for rendering image formats such as JPEG, PNG, and GIF using the <img> tag, and plain text files can be parsed and displayed using elements like <pre> or <code>. Implementation for previews of these file types is straightforward, and involves receiving the file from the application backend, and either referencing the file URL in the src attribute (in the case of images) of the <img> tag, or parsing its content for security purposes and rendering the content within a <pre> or <code> tag. 

For PDFs, while HTML does offer basic native support through the <embed> element, these options are limited in terms of styling, interactivity, and control. However, depending on the framework being used on the front end there may be other options which can help. 

For instance, in React-based applications for example, open-source packages such as react-pdf (which uses pdfjs as a dependency) allow developers to render PDFs directly within other custom React components, offering paging and scrolling, as well as font-family integrations. Tools like react-pdf integrate well with React applications, are maintained actively by the community, and can be styled and extended as much as needed to match any web application's design requirements.

For example, below is one implementation that our developers at Patient Zero have created using react-pdf to display pdfs, images, and plain text files on a modal component in a web UI application.

Conclusion

Delivering a rich feature like interactive preview of Word and Powerpoint files in a web application would have been prohibitively expensive not so long ago, but thanks to open-source tools like pdfjs and Gotenburg it is now a capability that any team can add to their product. Commercial tools like Telerik’s suite provide additional features like customisation options, document editing, and professional support. Either option can be used to deliver a robust solution, and it is possible you could end up using both in different situations if file previews are an important part of your application. Depending on the richness, type and size of documents you need to preview one of the two approaches may have clear advantages, so it is worth thoroughly testing your proposed solution with a variety of documents from your domain to ensure they are converted properly. Happy file previewing!