DEV Community

AsyncMonk
AsyncMonk

Posted on

Switching document delivery from attachments to a single web file

Distributing docs as a solo dev, I defaulted to PDF attachments. A few things grated over time: the recipient needs a PDF viewer, and different viewers wrap the content in different menus and toolbars; some viewers inject their own stuff into the file; worst, a PDF attachment is easy to casually forward and hard to constrain what it can do. So I started converting the PDFs I hand people to read into a self-contained web file first — and most of those grievances went away.

PDF to HTML workspace

This path is fully local — the whole PDF-to-HTML runs in the browser, no upload (unlike "HTML-to-PDF" in the same product, which has a server step; don't mix them up). Out comes a .html, double-click to open in a browser, layout matching the original PDF.

After switching, the gains are concrete. One, no external dependencies: the output is self-contained, links no external resources, so offline or years later it opens fine — it won't half-render because some CDN died. Two, no viewer shell: it shows as the content itself in the browser, no PDF-reader menu bar, annotation rail, or "open with X" prompts; the recipient sees clean content. Three, no bundled original PDF: what's sent is the rebuilt webpage, not the source PDF file, so I don't worry about handing the source along. Four, CSP limits its network ability: the output page is bound by a content security policy and can't freely fire requests outward — for something that's "out of my control once sent", that constraint keeps it well-behaved and reassures the recipient.

The boundary, so I don't oversell. It does fixed-layout reading, archiving, sharing — not rewriting the PDF into a phone-responsive article, nor a drag-to-edit web editor; the goal is "same as the original, viewable and selectable", not "reflowable". Complex graphics have an acceptance boundary: certain special transparency masks, CMYK print colours, and images that render differently across browsers get flagged on the page for manual check — it's not unconditional pixel-perfect (it declines "perfect / pixel-exact" claims itself). So I only take this path for "finalised, meant-to-be-read" docs; anything needing further editing, or with those complex features, still goes as the original format.

Net: from "send an attachment" to "send a web file", what changed isn't just the format — the thing you distribute is cleaner, more self-contained, more controllable: doesn't depend on what they installed, doesn't smuggle what I didn't mean to send, and stays put under CSP. For a solo product that often ships docs to outsiders, the switch pays off well — as long as you sort which docs should take this local path and which shouldn't. Tool is ImgIng (imging.ai).

Top comments (0)