Most PDF tools on this site produce output that behaves exactly like a normal PDF: text you can select, search, and copy. Two tools — HTML to PDF and Markdown to PDF — are honest exceptions, and it is worth explaining exactly why, because the trade-off they make is deliberate, not a bug.
Both tools rely on html2canvas, a JavaScript library that takes a rendered DOM element — your HTML content, or your Markdown after it has been parsed into HTML by markdown-it — and rasterizes it into a bitmap image, essentially taking a very precise, high-resolution screenshot of how the browser laid that content out. That bitmap is then placed onto a PDF page (or several pages, for longer content) using pdf-lib. The PDF you download is, structurally, an image embedded in a PDF wrapper, not a page of selectable text objects.
The reason for this approach is a genuine engineering trade-off, not laziness. Faithfully converting arbitrary HTML and CSS — with its flexbox layouts, custom fonts, background gradients, and endless styling edge cases — into a true PDF text layer would require re-implementing a meaningful chunk of a browser's own layout and text-shaping engine from scratch inside JavaScript, entirely client-side, which is an enormously larger undertaking than what a lightweight, honest, browser-only tool can reasonably deliver. Rasterizing what the browser has already laid out perfectly, using the browser's own rendering engine as the source of truth, sidesteps that entire problem: whatever you see rendered is exactly, pixel-for-pixel, what ends up in the PDF, with zero layout-translation bugs.
The real cost of that trade-off is that the resulting PDF text is not selectable, not searchable with Ctrl+F, and not accessible to screen readers the way genuine PDF text would be. If someone needs to copy a paragraph out of the output, or a document needs to pass an accessibility audit that specifically checks for a proper text layer, an image-based PDF from these tools will fail that requirement, and that is exactly why minipdftoosz flags this limitation directly on both tool pages rather than burying it in fine print.
In practice, this limitation matters far less than it might sound. A large share of what people convert with HTML to PDF or Markdown to PDF is visual by nature: styled invoices, formatted reports, README files rendered with their intended typography, or content meant purely to be printed or viewed rather than searched or copied. For that category of use case, a pixel-perfect image-based PDF that matches exactly what you designed is arguably the more honest output — it guarantees your careful formatting survives the PDF conversion completely intact, something a text-layer converter with imperfect CSS support genuinely cannot always promise.
If you specifically need a searchable, selectable, screen-reader-accessible PDF from plain text content, the PDF to Text tool's counterpart workflow — writing content and using a tool designed to preserve a real text layer rather than a rasterized one — is the better fit, and it is worth checking a tool's stated behavior before assuming "convert to PDF" always means the same thing under the hood. It rarely does.