Printing a .txt file straight from Notepad or TextEdit is unpredictable. Margins vary by application, long lines get chopped at the page edge instead of wrapping, and page breaks land wherever they land. For a shopping list that is fine. For a log file you need to annotate, or a code listing for a review, or exported notes you want to read on paper, it is not.
Converting to PDF first fixes the layout once, and it then prints the same way everywhere.
Converting
The text is laid out with proper margins, wrapped to the page width and paginated automatically. It runs in your browser, so log files and notes containing anything sensitive stay on your machine.
Choosing a font size
More consequential than it sounds, because it determines how much fits per line before wrapping.
If your content has long lines — log entries, stack traces, wide tables — a smaller size means fewer of them wrap, which makes the output far easier to follow. A wrapped log line splits a single event across two visual rows and makes scanning genuinely harder.
The line-wrapping problem
Plain text has no concept of page width. A log line can be 300 characters long. When it hits the page edge it wraps, and now one entry occupies three rows with no visual indication that they belong together.
Three ways to handle it:
Reduce the font size so more fits per line. Simplest, and often enough.
Use landscape orientation if your page size options include it. A landscape A4 page fits roughly 40% more characters per line.
Pre-process the text to truncate or reformat the long lines before converting. For logs, stripping timestamps or thread IDs you do not need often brings lines under the wrap threshold.
Code listings
Text to PDF handles code, with two caveats worth knowing.
Indentation is preserved as spaces, so structure survives. Tabs may render at a different width than your editor shows — if precise indentation matters, convert tabs to spaces before pasting.
There is no syntax highlighting. The output is monospaced black text. For a code review on paper that is generally fine. If you want colour, print from your editor or IDE, which will apply its own theme.
Encoding and special characters
If your text contains accented characters, currency symbols, or non-Latin scripts, make sure the source file is UTF-8. A file saved in an older encoding — Windows-1252 is the usual culprit — shows mangled characters after conversion.
Most editors let you check and change this. In Notepad it is in the Save As dialog; in VS Code it is in the status bar at the bottom right.
Emoji and less common symbols may not render at all, depending on what the PDF's embedded font covers. If a character matters and it comes out as a blank box, replace it with text before converting.
For structured documents
If your text is actually Markdown — with headings, lists and emphasis — use Markdown to PDF instead. It renders the structure rather than printing the markup characters literally, which is usually what you want.
For plain unstructured text, Text to PDF is the right tool and the simpler one.