Text to PDF

The one decision that matters: line breaks

Every text-to-PDF conversion hinges on a single question, and most tools get it wrong by not asking. Is a newline in your file the end of a paragraph, or just where the line happened to wrap?

In a file hard-wrapped at 72 columns — which is most .txt files, most email exports and every log — a newline is a wrap. Treating each one as a paragraph produces a PDF of short ragged fragments that is unpleasant to read and impossible to reflow. So by default this tool reflows: a blank line separates paragraphs, and single newlines inside a paragraph are joined back into flowing text that wraps naturally to your chosen page width.

But some text is already laid out, and reflowing it destroys it. An address block, a poem, a code listing, a log file, a set of subtitles, an ASCII table. For those, switch on "Keep every line break" and each line is preserved exactly as written. Neither behaviour is right for everything, which is why it is a switch you can see rather than a heuristic you have to fight.

Small structural touches

With reflow on, the tool also does two conservative bits of structure recovery. A run of lines that all begin with a dash, a bullet character or a number becomes a real list, indented with hanging text — which is how bullet points arrive from an email or a README and how they should look in a document.

And a short line standing alone, in capitals or numbered like "3. Scope", is treated as a heading. The rule is deliberately cautious: under 70 characters, not ending in a full stop, and either fully capitalised or numbered. Promoting an ordinary short sentence to a heading is more jarring than leaving a real heading as body text, so the tool errs towards leaving things alone.

Both behaviours turn off when you keep line breaks, on the reasoning that if you are preserving the original layout you do not want the tool reinterpreting it.

Why bother, when every OS can print to PDF

It is a fair question — macOS, Windows and every browser can print a text file to PDF. Three things make this easier in practice.

You can paste. A great deal of the text people need as a PDF is not in a file: it is in a chat window, an email, a terminal, a support ticket. Saving it to a file first, opening it in an editor and printing it is four steps that this replaces with one paste.

It typesets rather than prints. Printing a text file gives you the monospaced output of a text editor with whatever margins that editor felt like. This gives you a choice of proportional typefaces, a controlled margin, sensible line spacing, page numbers, and lines wrapped at a comfortable measure rather than at 80 characters regardless of the page.

And it is consistent. The same input produces the same PDF on any machine, which a print dialogue does not — printer drivers, default paper sizes and scaling settings all vary. When the output is going to a form, an upload or a filing system, that consistency is worth having.

Character sets, size and privacy

The PDF is written with the standard fonts every reader has built in, which is why the output is a few kilobytes rather than a few hundred. Those fonts cover Western European Latin, and the tool transliterates what it sensibly can: the rupee sign becomes Rs., arrows become their ASCII equivalents, exotic spaces collapse and zero-width characters are removed.

For text in Devanagari, Bengali, Tamil, Arabic, Chinese, Japanese or Korean, leave "Draw non-Latin text as an image" switched on. Those lines are then rendered by your browser's own text engine — which shapes them correctly — and placed on the page as images. They will look right, but they will not be selectable, and the tool says so rather than letting you discover it later.

As with every tool here, the text never leaves the tab. That is not a marketing line for this particular tool so much as a practical one: the things people paste into a text-to-PDF box are frequently the things they should be most careful with — server logs with credentials in them, chat exports, notes about a person.