HTML to PDF's Rasterized Output, Explained

The actual pipeline

1. Your HTML is sanitized — scripts and inline event handlers are stripped so nothing in the document can execute.
2. The sanitized HTML is written into an isolated, sandboxed, same-origin iframe — never the main Looty Tools page — so pasted CSS, like a rule targeting the page body, cannot visually or functionally affect anything outside that frame.
3. That frame is rendered and captured as a single tall screenshot image.
4. The screenshot is sliced into page-sized image strips, and each strip becomes one page of the output PDF.

What this means: no selectable text, no clickable links

Because every page of the output PDF is an image rather than real embedded text, you cannot select or search text in the resulting PDF, and links are not clickable — a link renders as styled text but has no active target once it is baked into a page image. If a fully text-based, searchable, accessible PDF is what you actually need, this is the wrong output format for the job; see "who this is right for" below.

Why this tradeoff was chosen

• It avoids sending your HTML to a server — the entire render happens in your own browser tab, so the document’s content never has to leave your machine to be processed.
• It avoids requiring a heavy headless-browser backend, the kind a server-rendered "print to PDF" service typically needs — the whole pipeline runs on ordinary client-side JavaScript.
• It can run entirely inside the browser tab you already have open, with no separate service to depend on.

What "processed locally" does and does not mean

Your HTML itself is processed locally in your browser and is never uploaded to Looty Tools. But "processed locally" is not the same claim as "no network activity at all": if your HTML references external images, web fonts, or stylesheets by URL, your browser will still make its own ordinary requests to fetch those resources while rendering the frame — the same way it would for any webpage that references external assets.

This tool can run entirely without any outside network request, but only when the HTML is genuinely self-contained: inline CSS, and images or fonts embedded as data URIs rather than linked externally. Do not assume "no upload to Looty Tools" means "zero network activity" if your document links out to other hosts.

Who this is right for — and who it is not

Right for: visual documents you just need to save or print as-is — receipts, formatted reports, one-off visual snapshots where a picture-perfect look matters more than editable or searchable text.

Not right for: anything that needs to remain a searchable, screen-reader-accessible, or archival text document. For that, export directly from whatever authored the original content — a word processor, a reporting tool, a CMS — rather than routing it through a rasterized conversion. See also html-to-pdf-supported-elements-and-image-limits for what specifically does and does not survive the render.