Written for security teams, and about our own product as much as anyone else's.

Introduction

This article is published on the blog of a free online document viewer. That is worth stating in the first line, because the genre it belongs to — "the hidden dangers of free PDF tools" — is usually a sales pitch wearing a lab coat, and you should read this one with that in mind.

So here is the disclosure up front. Doconut.app is a free hosted viewer. When you use it, your PDF is uploaded to our servers, rendered there, and deleted when your viewing session ends. Everything below about the structural risks of uploading a document to somebody else's infrastructure applies to us too. We are not going to argue otherwise; we are going to be specific about what we do and do not do, and let you decide which documents belong here.

1. The risk is structural, not exotic

The interesting risks are not zero-days. They are the ordinary consequences of the file being somewhere you do not control.

The upload is real. A hosted viewer has to receive the document in order to render it. Anyone claiming a hosted service where "the file never leaves your machine" is either describing a purely client-side tool or describing something inaccurately. On Doconut.app the upload runs over HTTPS, which protects it in transit — and then the file is on our servers, because it has to be.

Retention is a promise, not a mechanism you can inspect. We say the file is deleted when the session ends. That is true, and you cannot verify it from outside. This is the core of the problem with every free viewer, including this one: you are extending trust to an organisation you have no contract with.

Shared infrastructure is shared. A free public service processes many customers' documents on common infrastructure. That is a different risk posture from software running inside your own network, regardless of how carefully it is operated.

No agreement means no legal basis. If you handle personal data under GDPR, or PHI under HIPAA, moving a file to a processor with no Data Processing Agreement or Business Associate Agreement in place is a problem at the moment of upload — whether or not anything is ever breached. Doconut.app has no DPA and no BAA with you. For regulated material, that is the whole answer, and no amount of encryption changes it.

2. What we do not do

The genre this article belongs to tends to promise everything. Since the point here is calibration, the more useful list is what is absent:

No security certifications. No ISO 27001, no SOC 2, no HIPAA attestation, no PCI DSS assessment. Not for the free sites, and not for the SDK. If your vendor questionnaire asks for a certificate, we do not have one.
No audit log. There are no accounts on Doconut.app, so there is nothing to attribute an access to and no trail to hand you.
No metadata stripping. We render the document as it is. Author names, revision history and comments in the file stay in the file — which is worth knowing before you forward a contract, though that risk belongs to the document rather than to us.
No encryption at rest to speak of. We do not offer encrypted storage, because we do not offer storage. Not keeping something is a stronger property than encrypting it, but it is a different property, and vendors blur the two.
No configurable retention. The timing is ours. There is no setting for you to adjust.

3. What we do

The upload runs over HTTPS.
The document is rendered on our servers, and the browser receives pages rather than the source file.
Rendering is not execution: macros in an Office file do not run, and PDF actions are not triggered. The viewer draws the document.
The file is deleted when the viewing session ends. No library, no history, no account.
The uploader refuses what it cannot handle before sending — a fixed list of 70+ extensions, with a size ceiling per format from 5 MB to 25 MB.
DICOM is deliberately excluded. .dcm and .ima are not accepted, precisely because a DICOM file carries patient identifiers alongside the image and a public upload endpoint is the wrong place for it.

4. A test you can apply to any free viewer, including this one

Rather than a threat inventory, four questions that separate the usable from the unusable:

Does it say plainly whether the file is uploaded? If the answer is vague, assume it is uploaded.
Does it state a retention period in specific terms? "Deleted when your session ends" or "removed after 60 minutes" are answers. "Your files are safe with us" is not.
Will it sign an agreement? For regulated data this is the only question that matters, and free services almost never will. We do not.
Does it claim certifications? If so, ask for the certificate and its scope. A great many claims in this category do not survive that request.

Applied to Doconut.app: yes it uploads, yes deletion is at session end, no we will not sign a DPA, and no we hold no certifications. That combination is fine for a great many documents and disqualifying for some. The point is that you can tell which is which.

5. When a hosted viewer is the wrong tool

If the document is subject to a compliance regime, covered by a client confidentiality obligation, or simply something you would not be comfortable explaining in an incident review, no free hosted viewer is the right answer — ours included. The structural fix is to keep the rendering inside your own network.

That is what the Doconut SDK is for: the same .NET rendering engine behind this site, installed in your own environment. It renders on your servers and makes no calls out to us, so the document never crosses a boundary you have not already assessed.

Be equally clear about what the SDK is not. It does not ship encryption at rest, key management, an identity provider integration or an audit log, and it cannot make your application compliant with anything. Those controls are yours — which is the point, because they are also the ones you can already evidence. A component that runs inside your network and calls nobody is an architectural argument, and for most security reviews it is a more useful one than a certificate belonging to a third party.

Conclusion

Free PDF viewers are genuinely useful, and most documents most people handle are not sensitive. The failure is not using one; it is using one without knowing which category your file is in.

For an ordinary document you need to read once, a viewer that keeps nothing is a reasonable choice — and safer than downloading the file and opening it in whatever happens to be installed. Doconut.app will do that, free, with no account, and delete it afterwards.

For anything under an obligation you would have to defend, keep the processing on hardware you control.

Immediate actions

Audit the PDF workflows in your organisation and catalogue the free tools already in use — there are usually more than anyone expects.
Classify which document types may go to a hosted service at all. This is a policy decision, not a technical one.
Move the rest in-house, whether with the Doconut SDK or an equivalent, and keep the evidence your auditors will ask for.