Introduction
Public file conversion is convenient, but it is not without security questions. Data can leak, retention can be unclear, compliance obligations may expand, and malicious files can target complex parsers. For .NET teams, those concerns should be addressed before an external converter becomes part of a business workflow.
Doconut offers a self-hosted .NET viewer and conversion workflow that can keep supported document processing inside infrastructure controlled by the application owner. That can reduce reliance on a public converter, but the application must still implement access control, secure transport, storage policy, cleanup, patching, and monitoring.
Secure File Conversion and Encryption for .NET Apps
Why encryption matters
When you toss a file at a cloud converter, it has to travel over the public internet. If the transport isn’t locked down, a hacker can sit in the middle and snatch the data—classic “man‑in‑the‑middle” style. Even with HTTPS, many free tools still stash the file on a shared server without extra encryption, leaving it exposed to insider threats or mis‑configured storage buckets.
What the two Doconut products actually do
They answer this differently, and conflating them is how people end up with a security design that does not hold.
The Doconut SDK is installed in your own environment. Rendering happens on your server, and the component makes no calls out to Doconut. That is the whole security argument, and it is a strong one: the file never crosses a boundary you do not control, so there is no third-party retention question to answer.
What the SDK does not do is encrypt your storage for you. There is no AES-256-at-rest feature, no key management and no built-in audit log. Those are your platform's, and you almost certainly already have them — which is the point. Anyone claiming a viewer library makes your application audit-ready is selling you something.
Doconut.app is our free hosted site, and it is a genuine upload: the file reaches our servers, is rendered there, and is deleted when the viewing session ends. Transport is HTTPS. There is no account and nothing kept afterwards. For a document you would not mind reading on a train, that is fine; for regulated data it is not, and we would rather say so.
Automatic file deletion and lifecycle management
The hidden danger of lingering files
Many cloud converters promise “automatic deletion after conversion,” but the definition of “after” varies widely. Some services keep files for hours, days, or even weeks, creating a window where confidential documents could be accessed by unauthorized personnel or retrieved through forensic analysis. For enterprises handling contracts, design blueprints, or personal data, that window is unacceptable.
Doconut App’s definitive answer
- On Doconut.app – The file exists for the duration of the viewing session and is deleted when it ends. There is no retention setting for you to configure, because there are no accounts and no administrators; the timing is ours. Printing is available to anyone viewing, via Ctrl+P.
- In the SDK – The lifecycle is yours. The component writes temporary render output somewhere you configure, and you are responsible for cleaning it up. This is the single most commonly skipped step in an integration, and orphaned render files in a temp directory are exactly the ghost-file problem this section warns about. Check where it writes, and schedule the cleanup.
- Controlled printing is part of the viewer rather than a separate plugin, so restricting print and download for particular roles is a configuration and permissions question inside your application.
Compliance‑ready cloud‑based viewing for regulated industries
Regulatory pressures
Healthcare (HIPAA), finance (PCI DSS), and government (FedRAMP) all impose strict rules on how data is transmitted, stored, and destroyed. A cloud converter that stores files on a shared multi‑tenant server can quickly become a compliance nightmare, requiring costly exception processes or outright abandonment of the tool.
Where Doconut stands, stated plainly
We hold no certifications. No ISO 27001, no SOC 2, no HIPAA attestation, no PCI DSS assessment, no FedRAMP authorisation. Neither the free sites nor the SDK. If a vendor questionnaire asks for a certificate, the honest answer is that we do not have one to give you.
No software component can make your application compliant in any case. These frameworks ask about processes, access control, retention, evidence and people. A rendering library is one control among dozens.
What the SDK offers a regulated environment is architectural rather than documentary: because it runs inside your infrastructure and calls nothing external, the document never leaves the boundary you have already assessed. For most reviews that is the more useful answer than a certificate belonging to somebody else, and it is the one you can evidence yourself.
Doconut.app is the opposite case and should be treated as such: a public site, shared infrastructure, no contract, no DPA and no BAA. Do not put regulated data through it.
Preventing malware and code injection in online document conversion
The hidden threat of malicious payloads
File formats like PDF, Office, and CAD can embed scripts, macros, or malformed data that trigger exploits in vulnerable rendering engines. A cloud service that processes files on a shared server may inadvertently execute malicious code, compromising the service and any downstream customers.
How the rendering model affects this
Be accurate about where the parsing happens, because the threat model depends on it entirely: Doconut renders server-side. The document is parsed on the server and the browser receives rendered pages. It is not a client-side WebAssembly viewer.
What follows from that:
- The browser is not the attack surface – no plugin, no ActiveX, and the user's machine never receives the source file, only rendered output.
- The server is the surface, and it is your server when you run the SDK. A parser processing untrusted input is a parser processing untrusted input; run it with least privilege, keep it patched, and treat uploaded bytes as hostile. The advantage over a public converter is that this is your isolation to design and verify, not a claim you have to take on trust.
- Rendering is not execution – macros in a .docm or .xlsm are not run, and scripts in a PDF are not executed. The viewer draws the document.
- The extension list is a whitelist – the free viewers accept 70+ extensions and refuse everything else at upload.
None of that is a substitute for scanning uploads if your risk assessment calls for it. Add that layer yourself; the viewer does not include malware scanning.
A viewer that fits established .NET application styles
The integration challenge
Enterprises often run a mix of ASP.NET Core, MVC, WebForms, and newer Blazor applications. Adding a third‑party viewer usually means juggling JavaScript libraries, dealing with plugin compatibility, and fighting browser quirks. Each extra dependency introduces a new attack surface and a maintenance burden.
What the SDK does about that
- Zero‑plugin, pure HTML5 – Works on every modern browser (Chrome, Edge, Firefox, Safari) without installing anything on the client machine.
- Blazor integration – Coordinate viewer state from a component while keeping file access and processing on the server. Follow the documentation for the installed SDK version.
- Customisable UI – The viewer's toolbar, colours and branding can be tailored to match your application, so it reads as part of your product rather than a window into someone else's. Take the option names from the documentation for the version you installed.
Embedding the viewer
Add the supported Doconut package, enforce document authorization in the ASP.NET application, and initialize the viewer using the official documentation for that version. Do not assume that transport, encryption, deletion, or UI permissions are automatic; verify and configure each control in the deployed architecture.
Blazor integration and evaluating it
Doconut can participate in Blazor application workflows, but the exact component model and setup depend on the installed SDK version. Authentication, secure transport, storage protection, cleanup and process isolation must be verified in the complete deployed architecture rather than assumed to be enabled automatically.
For evaluation, the download page has the trial licence and the documentation; the terms and what each edition includes are on the pricing page rather than summarised here, where it would go out of date.
If all you want first is to see how a particular awkward file renders, Doconut.app runs the same engine on one file at a time, free — and deletes it afterwards.
Key Takeaways
- The SDK's security property is architectural – it runs in your environment and calls nothing external, so the document never leaves your boundary. It does not ship encryption at rest, key management or audit logging; those stay yours.
- Doconut.app is a real upload – HTTPS in, rendered on our servers, deleted when the session ends, no account. Fine for an ordinary file, wrong for regulated data.
- Compliance is not built in – we hold no ISO 27001, SOC 2, HIPAA, PCI DSS or FedRAMP credential, and no component can confer one.
- Rendering is server-side, not WebAssembly – the browser gets pages, never the source file. Rendering is not execution, so macros do not run.
- Clean up your temp directory – in a self-hosted deployment, orphaned render output is the realistic ghost-file risk.
- Zero-plugin browser experience – integrates with ASP.NET Core, MVC, WebForms and Blazor workflows.
- Evaluate in your own environment – rendering quality is free to check on Doconut.app; everything else needs the trial on your own servers.
Common Questions
Q: Does Doconut.app keep a copy of my document after viewing? A: No. It is rendered in a temporary session tied to your browser and deleted from our servers when that session ends. There is no account for it to be attached to and no library it could reappear in. In a self-hosted SDK deployment the equivalent question is about your own temp directory, and the answer there depends on the cleanup you configure.
Q: Can I enable downloading or printing for specific users? A: In the SDK, yes — the viewer's controls are configurable and controlled printing is part of the viewer rather than an extra plugin, so you can grant those rights per role from your own application. On the free site at Doconut.app there are no roles and no API: anyone viewing can print with Ctrl+P.
Q: How does it handle large CAD or high-resolution image files? A: The engine renders DWG, DXF, DGN, PSD, TIFF and DNG from the geometry and pixel data rather than from an embedded preview, applies embedded ICC profiles, and lets you switch CAD layers off and measure distances and areas. On the free site the ceilings apply: 10 MB for CAD, which issued drawings do exceed, and 25 MB for PSD, TIFF and images. Self-hosted, the ceiling is your server's memory.
Q: Is the viewer compatible with mobile browsers? A: Yes. Because rendering happens on the server and the browser receives ordinary HTML and images, it works on iOS Safari, Android Chrome and any modern mobile browser — and a weak device is not a disadvantage, since it is not doing the work.
Q: What does it cost? A: Doconut.app is free, with no paid tier, no account and no trial to expire — that is the entire model. The SDK is a commercial licence with a free trial; current editions and prices are on the pricing page, which is the authority rather than this article.
Final Thoughts
When you embed a cloud-based file converter into an enterprise .NET application, data exposure, uncertain file lifecycles, compliance gaps, and malicious payloads are real risks. A self-hosted Doconut workflow can give Windows-based .NET teams more control over processing and storage, while the surrounding application remains responsible for the complete security design.
Deciding between them? If the documents are ordinary, Doconut.app will open one right now for nothing. If they are not, the argument for the SDK is that the file stays on your servers — and the work of proving that to an auditor stays yours, which is the only version of this that survives contact with a real security review.