PDF

A PDF viewer that does not hand over the PDF

The browser's built-in PDF viewer works by giving the user the file. For a contract, a medical record or a sealed bid, that is often precisely the thing you are trying not to do. Doconut renders pages server-side and sends images, so viewing and possessing stop being the same act.

0
bytes of source PDF sent to the client
100%
server-side rendering
1
viewer for every other format too

The problem

Three ways to show a PDF, and what each one costs

Serve the file and let the browser render it: simplest, and it hands the user the original bytes, the metadata, the embedded attachments and the ability to forward all of it in one click.

Ship a JavaScript PDF engine: keeps the file in the browser too, adds a meaningful download to your bundle, and still leaves you writing the toolbar, the thumbnail rail and the search box yourself.

Render server-side and send images: the user sees the pages, the file never leaves your infrastructure, and the same mechanism happens to work for Word, Excel, CAD and email — which is usually the requirement that arrives two sprints later.

Capabilities

What the viewer does with a PDF

Paginated page images

Each page is rasterized server-side and delivered on demand. Large documents open at the first page rather than after the whole file downloads.

Text-layer search

With the AdvancedSearch plugin, full-text search runs against the PDF's text layer, so hits land on the right page with the right highlight.

Thumbnails and navigation

A thumbnail rail, page jumps, zoom and fit-to-width come with the widget. Set showThumbs and FitType and move on.

Annotations

With the Annotation plugin: highlights, comments, stamps and signatures, stored and exported by your application rather than embedded back into the source file.

Password-protected files

Encrypted PDFs open server-side with a password your code supplies. The password never reaches the browser.

Printing under your control

Print is a viewer capability you can expose or withhold, which is a different decision from whether the user may download the original.

Integration

Opening a PDF

The client receives only the token. It never learns the filename, the storage location, or that the document was a PDF rather than anything else in the catalogue.

Supported extensions

.pdf
csharp
// Server-side: returns an opaque token, never a path or a URL
app.MapPost("/api/open", async (Viewer viewer) =>
{
    string token = await viewer.OpenDocumentAsync("wwwroot/files/Contract.pdf");
    return Results.Ok(new { token });
});

// For an encrypted PDF, supply the password server-side —
// it is used to decrypt in your process and goes no further.

Details

PDF specifics

  • Text-layer search requires the AdvancedSearch plugin; OCR is not generally available and should not be assumed for scanned pages.
  • Annotations require the Annotation plugin and are stored by your application, not written back into the source PDF.
  • Converting PDF to Word, Excel or an image requires the Converter plugin and DocumentConverter.ConvertAsync().

Frequently asked questions

Can the user still download the original PDF?

Only if you build that yourself. The viewer delivers page images addressed by an opaque token, so releasing the source file stays an explicit decision in your own code rather than a side effect of letting someone read it.

Does it work on scanned PDFs with no text layer?

They render fine as images, but there is nothing to search. OCR ships only through the AdvancedSearch plugin and is not generally available — the engine is being re-based, so do not plan around it today.

How large a PDF can it handle?

Pages are rendered and delivered on demand rather than all at once, so document length affects memory far less than page complexity does. Very heavy vector pages are the real cost driver, not page count.

Try it against your own documents

A temporary licence takes a few minutes to request and runs entirely on your own machine. The files that matter are the ones already breaking your current viewer.