Search DevTools

Jump to any tool or page

Text to PDF

Write rich text with headings, lists, links and images, then export it as a PDF via print, HTML, or in-browser canvas rendering.

Editor

images embed as base64

Preview

Write something in the editor and the preview appears here.

Tips for perfect PDFs

  • Images: base64 embeds print reliably. If you switch to hosted URLs, ensure CORS allows canvas use.
  • Colors/backgrounds: turn on "Background graphics" in the print dialog for exact output.
  • Sanitization: editor output is sanitized with DOMPurify before preview/export.
  • Page size: the canvas flow slices content into A4 pages (210×297 mm).
Data Transformation

About Text to PDF

Paste or type text, apply basic formatting, and generate a downloadable PDF in the browser. PDF has no reflow model — the generator must decide line breaks, page breaks, and glyph positions itself, because a PDF stores text as positioned runs on a fixed canvas rather than as a document that a viewer lays out.

Frequently asked questions

Why do non-Latin characters come out as blank boxes or garbage?
The 14 standard PDF base fonts use WinAnsi or Standard encoding, which covers little beyond Latin-1. Devanagari, Chinese, Arabic, and even the smart quotes and dashes copied from a word processor fall outside it. Rendering them needs a TrueType font embedded in the PDF with a proper Unicode-to-glyph mapping, which adds hundreds of kilobytes per subset. If your text is not plain Latin, confirm the output before distributing it — the failure is silent at generation time.
How are line and page breaks decided, and why does text overflow?
The generator measures each word against the remaining line width using the font's advance-width metrics and wraps greedily. Two things defeat it: strings with no break opportunity, such as a long URL or a base64 blob, which overrun the right margin because there is nowhere to split; and tabs, which are not layout instructions in PDF and are typically collapsed to a single space. Insert explicit breaks in long unbroken tokens if you need them to wrap.
Is the text in the output searchable and selectable?
Yes, provided the text is drawn as text operators rather than rasterised. Search works when the font carries a ToUnicode CMap that maps glyph identifiers back to code points; without one, a viewer renders the page correctly but copying yields nonsense because the glyph indices have no character meaning. Subsetted fonts are the usual culprit. If you need reliable extraction downstream, verify by copying a paragraph out of the generated file.
What sizes should I use — points, pixels, or millimetres?
PDF's native unit is the point, defined as 1/72 inch, and the coordinate origin sits at the bottom-left of the page with y increasing upwards — the opposite of CSS. A4 is 595.28 by 841.89 points; US Letter is 612 by 792. Specifying font sizes in pixels only works if the tool assumes a 96 DPI conversion, which introduces rounding. Working directly in points avoids a class of off-by-a-fraction margin errors.
Why is my file larger than expected for a page of plain text?
Text content compresses to almost nothing; the weight is in embedded fonts. A full CJK TrueType face runs to several megabytes, and even a Latin face with regular, bold, and italic variants adds a few hundred kilobytes before subsetting. Subsetting keeps only the glyphs actually used and cuts this dramatically, but it must be done at generation time. Using the base-14 fonts avoids embedding entirely, at the cost of typeface choice and Unicode coverage.