How do I turn a text file into a PDF that keeps its layout?

Plain text looks like the easiest thing in the world to convert. It is just characters. There is no formatting to preserve.

That is exactly why it goes wrong. Plain text has no formatting instructions, so every decision about how it should look is made by whatever is doing the converting — and the usual defaults are the wrong ones.

Three ways it breaks

Tabs collapse. A tab is one character that means "move to the next tab stop". Software that treats it as a single space turns a neatly aligned table into a ragged mess. Software that treats it as eight spaces regardless turns an already-aligned table into a differently ragged mess. Neither is what the file meant.

Long lines get cut. Text files have no page width. A log entry can be 300 characters long. Cut it at the page edge and you have lost the end of the line — usually the part with the error message in it.

The font is proportional. This is the big one. In a proportional font an "i" is narrower than an "m", so two lines with the same number of characters are different lengths, and any alignment built from spaces disappears. Everything that depended on columns lining up stops lining up.

What the file actually needs

A monospaced font, where every character occupies the same width. This is the whole reason terminals, code editors and log viewers use them. Column alignment made out of spaces only survives in a monospaced font, and plain text alignment is always made out of spaces.

Tabs expanded to real stops, normally every eight columns, matching what almost every editor does.

Long lines wrapped, not cut, with the continuation clearly indented so a wrapped line does not read as a new one.

TXT to PDF does all three, and lets you set the text size so you can decide how much line length to fit before wrapping starts.

Choosing a text size

The trade-off is straightforward: smaller text fits longer lines before wrapping, at the cost of readability.

• 10-11pt — comfortable prose. Wraps around 90 characters on A4 portrait.
• 8-9pt — good for logs and code. Around 110-120 characters.
• 7pt or below — fits very wide output, hard to read on paper.

If your lines are long, switching to landscape buys more than shrinking the type does, and costs nothing in readability.

Character sets, and where tofu comes from

A .txt file does not reliably state its encoding. Most modern files are UTF-8, which covers every script. Older files, especially from Windows, may be in a regional code page.

When the encoding is guessed wrong, accented Latin characters turn into pairs of nonsense symbols, and non-Latin scripts turn into rows of empty boxes.

That second case has a second cause worth separating: even with the encoding read correctly, the font must contain the characters. A monospaced font designed for code may have no Bengali or Chinese glyphs at all, and an empty box is what a viewer draws when a character has no glyph.

When a text file is really a table

If the "text file" is columns separated by commas, semicolons or tabs, it is a data file wearing a .txt extension, and CSV to PDF is the better tool. It measures each column against its contents, draws real rules, and repeats the header on every page — none of which a text renderer can do, because to a text renderer a comma is just a comma.

The tell: open it and look at the first line. If it reads like a row of field names, treat it as data.

When it is really a document

If it is prose that wants headings, bold and proper paragraphs, converting it as plain text will look like a printout of a terminal, because that is what it is. Paste it into a word processor, apply styles, and use Word to PDF instead. Monospaced type is right for structured text and wrong for reading.

A short checklist

1. Is it prose, a table, or structured text? Pick the tool from the answer.
2. Look at the longest line and choose a size, or switch to landscape.
3. Check the result for empty boxes if it contains anything but plain English.
4. Check that tabbed columns still line up.

Line endings, and the stray characters at the end of every line

Windows ends a line with two characters, carriage return and line feed. Unix, Linux and macOS use one.

Most software handles both silently. Some does not, and when it does not you see one of two symptoms: an extra blank line between every line of text, or a small box or caret at the end of each one.

If your converted PDF is double-spaced when the file was not, this is why. Opening the file in a text editor that can convert line endings — most can, usually under a menu called Line Endings or EOL — and saving it as the other kind fixes it in one step.

Converting code

Code is structured text, so everything above applies, plus two things specific to it.

Indentation is meaning. In Python especially, the indent level is the syntax. A converter that mishandles tabs does not just make it ugly, it makes it wrong. Expanded tab stops are essential rather than cosmetic.

There is no syntax highlighting. A plain text renderer draws characters; it does not parse the language, so everything is one colour. That is honest — colouring would require the converter to know the language and guess when it did not — but if you are producing something for people to read carefully, print from an editor that highlights instead.

For an appendix, a code review record, or an archive copy, plain monospaced output is exactly right and highlighting would be noise.

A quick sanity check before you send it

Open the PDF and look at three things:

1. The longest line. Did it wrap, or was it cut? Cut means the tool got it wrong.
2. Any indented block. Do the levels still line up?
3. The last page. A file with trailing blank lines can produce an empty final page, which looks like an error to whoever receives it.