TXT to PDF

The file picker reads your .txt through the browser FileReader API, which detects UTF-8 (with or without BOM), UTF-16 LE/BE, and falls back to the operating-system default for legacy encodings like Windows-1252 or ISO-8859-1. UTF-8 is the safe default — every modern text editor (VS Code, Notepad, TextEdit, Sublime, Vim) writes UTF-8 unless you tell it otherwise. If your output PDF shows boxes or question marks instead of accented letters, the source file is in a legacy encoding; open it in your editor, "Save as" UTF-8, and re-upload. The Helvetica, Times, and Courier fonts bundled with PDF only cover the WinAnsi character set — for full CJK or Cyrillic, see the next question.

Not directly. The three font choices (Helvetica, Times, Courier) are the PDF Standard 14 fonts, which only cover WinAnsi (Latin + Western European). Characters outside that range — Chinese hanzi, Japanese kana, Arabic, Cyrillic, Greek, Hebrew, Thai — appear as missing glyphs (boxes) in the output. For text in those scripts, type or paste into Type/paste mode, then export from a richer formatting tool, or use our other workflow: paste your text into Word, save as DOCX, and run Word to PDF — that pipeline embeds a Unicode font that covers all common scripts. We may add Unicode font embedding here in a future update.

Hard line breaks (\n and \r\n) in your source text are preserved as paragraph breaks in the PDF. Tabs are converted to four spaces during layout. Long lines that exceed the available text width are soft-wrapped at word boundaries; the original wrap from your editor is ignored so you do not get awkward orphan words when you change the page size or margin. Justify alignment expands inter-word spacing on every line except the last of each paragraph. If you need exact monospace formatting where character columns must line up (ASCII art, code, tables), pick Courier with Left alignment — that combination keeps every character at the same column position.

No. The textarea content stays in the page; the .txt file you upload is read through FileReader (which never touches the network); the PDF is built locally using pdf-lib (WebAssembly) on a Blob and offered to you as a direct download. You can see this in DevTools Network: no outbound POST carries your text. This matters if you are converting drafts, journal entries, source code, notes containing credentials, or any text you would rather not hand to a server. Closing the tab discards the textarea contents — nothing is persisted in localStorage either.

Yes. Page size offers A4 (210 × 297 mm), Letter (8.5 × 11 in / 216 × 279 mm), and Legal (8.5 × 14 in / 216 × 356 mm). Margin presets are 10 mm, 20 mm (default — matches Word/Pages default), and 30 mm, applied uniformly on all four sides. Line spacing options are 1.0 (tight, like single-spaced typed text), 1.15 (default — slightly looser, like the Microsoft Word default), 1.5 (school essay), and 2.0 (double-spaced for printing-and-editing). Font size goes from 10 pt up to 24 pt. There is no "first-line indent" or "space after paragraph" control yet — paragraphs are separated by a blank line if the source text has one.

In practice, anything up to a few megabytes of plain text works fine — that is hundreds of pages, far beyond a normal document. The tool keeps the entire text in memory, lays it out, and renders the PDF synchronously on the main thread; very large files (10+ MB of text, tens of thousands of lines) may freeze the browser tab for several seconds during layout. There is no hard upper limit imposed by us. Each page in the resulting PDF only stores the text and a font reference, so file size is dominated by the embedded font (~30 KB for Helvetica), not by the number of pages.