Drop the file and press the button. Every line stays where it is by default, which is what you want for anything machine-written, and reflow is one control away for anything human-written.
The encoding is worked out and reported. A text file does not record how it was written, so this is always a guess, and a guess worth showing you rather than making quietly.
Text files are the last format with no opinions. That sounds like it should make conversion easy and it does the opposite: every question a real document format answers for you is still open when you have only bytes.
Three things a text file does not contain
- Which encoding wrote itguessed, then reported
- Page size and marginsA4 by default
- Whether lines are lineskept by default
- Any typeface at allNoto Sans, embedded
The first is the one that bites. The rest are cosmetic choices you can see and change; the encoding is invisible until a name comes out as Müller or Müller, and by then the file has been sent.
The encoding guess, and why it is a guess
A .txt file is bytes. Nothing in it says whether byte 0x92 means a right single quotation mark, an unprintable control code, or part of a Chinese character. Working it out is inference, and the order matters.
So the result line always names the encoding it settled on. If it says Windows-1252 and the text looks wrong, the file was written in a third thing, and the fix belongs upstream: re-save the original as UTF-8 in whatever produced it.
Keep the lines, or reflow them
This is the only choice on the page that changes what the document says, and it depends entirely on who wrote the file.
A log, a config file, a code listing, a data dump.
Line breaks carry meaning and columns line up.
Set in a monospaced face so they keep lining up, unless the file needs characters that face cannot draw.
A line too long for the page wraps rather than being cut.
A letter, a note, a chapter, anything written to be read.
Blank lines separate paragraphs; single breaks are just where the author pressed return.
Text fills the width like a normal document.
Set in the same proportional face as the rest of the site's output.
The default is to keep them, because getting it wrong that way is obvious and recoverable: a letter with short ragged lines looks odd but reads fine. Getting it wrong the other way silently destroys a table that was made of spaces.
Lines that do not fit
A text file has no width, so a line can be two thousand characters long and nothing in the file objects. On a page it has to go somewhere.
Long lines wrap onto the next line rather than being cut off, which loses nothing but does make a wrapped listing harder to follow. Three things help, in order of how much they cost: landscape, which buys about forty per cent more width; a smaller type size, which buys more still; and A3, which is the honest answer for a wide fixed-width report that has to stay readable.
When a text file is not what you should convert
- It is Markdown. The marks are meant to become formatting. Markdown to PDF renders the headings, lists and tables instead of printing the asterisks.
- It is really a table. A file of comma or tab separated values wants columns, not lines. CSV to PDF lays it out as a grid.
- It is a log you need to search, not print. A PDF is a worse text file than a text file. Convert when somebody needs a fixed, sendable, signable artefact, not for storage.
Why this runs in your browser
Plain text is what people paste secrets into. Exported credentials, database dumps, server logs with addresses in them, drafts nobody has seen. It is the format with the fewest defences and the least ceremony, which is exactly why it should not be uploaded to a converter.
The file is read into memory, laid out with an embedded font, checked by reopening the result with the same engine your browser uses, and handed back. Nothing is transmitted.
The tool is right above
Line breaks kept, encoding reported, nothing uploaded.
Common questions
What gets decided on your behalf, and how to override it.
01Will my line breaks be kept?
By default, yes. Every line in the file becomes a line on the page, which is what a log, a configuration file or a code listing needs. Switch to reflow if the file is prose and you would rather it filled the width.
02My accented characters look wrong. Why?
The file was probably not UTF-8. A text file carries no record of its encoding, so reading one is a guess: the tool tries UTF-8 first, falls back to Windows-1252, and tells you which it used. Re-saving the original as UTF-8 fixes it properly.
03Does it handle Greek, Cyrillic or accented letters?
Yes, and it says what it had to do to manage it. A PDF's monospaced font only speaks Latin-1, so a file containing Cyrillic cannot be set in it. Those files are laid out in the embedded Unicode face instead: line breaks and indentation are kept, exact column alignment is not, and the result line says so. CJK, Arabic and Indic are not covered yet and are reported rather than dropped.
04What about very long lines?
In line-keeping mode a line too long for the page wraps rather than being cut off. If that is happening a lot, landscape or a smaller type size usually reads better than the wrapping does.
05Can I convert a .log or a .md file?
Yes, both are plain text and both work here. For Markdown, the dedicated converter renders the headings, lists and tables as formatting instead of showing the marks.
06Is the text in the PDF selectable?
Yes. It is real text with an embedded font, not a picture of text, so it selects, copies and searches.
07Are my files uploaded anywhere?
No. The file is read and the PDF built in your browser. Nothing leaves the device.
08Is it free?
Free. Every tool, unlimited use, no signup.