Embedding Documents on the Web as Images: When It Works and When It Fails People

There is a genuinely useful pattern where a document — a policy page, a spec sheet, a slide deck, a technical drawing — is rendered to images and embedded directly in a web page. No PDF viewer, no download prompt, no assumption that the visitor owns Office. It just appears.

WebP is a good fit for this specific job, and the pattern has one serious drawback that is easy to overlook.

Why WebP suits document rendering

Page renders are large images consisting mostly of flat white with sharp black text — content that compresses extremely well. A rendered page as WebP is typically around half the weight of the equivalent JPG render, which means a twenty-page document stays light enough to serve inline rather than forcing a download.

Text sharpness matters here, and it is worth using lossless WebP for text-heavy pages. Lossy compression puts a visible fuzz around glyph edges that looks like a rendering fault rather than compression, and on a page that is 90% flat white, lossless is often smaller anyway.

Setting DPI correctly

DPI controls the render resolution and it is the setting that most affects the result. 150 DPI is right for screen display and produces legible body text. 300 DPI is worth it if visitors might print the images or zoom in on fine detail such as a CAD drawing's dimension annotations. Below 150, small text starts to break down.

Higher DPI means proportionally larger files, so for a long document it is worth rendering at 150 and only bumping specific pages that need it.

The accessibility problem

This is the part that gets skipped. A rendered page is a picture of text, not text. That means:

• Screen readers cannot read it. To a blind visitor the page is empty.
• It cannot be searched — neither by the visitor with Ctrl+F nor by search engines indexing the page.
• It cannot be copied, quoted or translated.
• It does not reflow, so on a phone the visitor is pinch-zooming a desktop-width page.

In several jurisdictions, public-sector and large-organisation websites have legal accessibility obligations that image-only documents straightforwardly fail.

How to do it responsibly

Always offer the source document as a download alongside the images. This is the minimum, and it is one line of HTML.

Write real alt text — not "Page 3" but an actual summary of what the page contains. For a short document, transcribing the key content into the alt attribute is reasonable.

Put the important content in real HTML too. If the document contains information visitors actually need — prices, dates, contact details, policy terms — that information belongs in the page as text, with the rendered image as a visual supplement rather than the sole carrier.

Consider OCR if you are working from documents you no longer have editable sources for. It is imperfect, but searchable imperfect text beats no text.

When the pattern is genuinely the right call

Visual documents where the layout is the content: technical drawings, org charts, infographics, design mockups, slide decks where the visual composition matters. In those cases a rendered image is not a degraded version of the document — it is a faithful one, and the accessibility answer is good alt text plus the source file.

Where it is the wrong call: anything that is fundamentally text. A policy, a FAQ, a set of terms, a price list. Those should be HTML, and rendering them to images is choosing convenience for the publisher over usability for everyone else.