How to Convert a TXT File to Word
To convert a TXT file to Word, drop it into the tool below and download the .docx — it opens in Word, Google Docs, Pages and LibreOffice, and nothing is uploaded. The conversion itself is trivial, because plain text has no formatting to lose. The part that goes wrong is character encoding: a text file does not record which alphabet its bytes stand for, so accented letters, curly quotes, dashes and currency symbols are the things that arrive broken.
Convert your TXT file to Word
or drag and drop a .txt file here
Processed on your device — files are never uploaded to Filesvo.
A .txt file does not record its own encoding — that is the whole problem
Every other document format states, inside the file, which character encoding it uses. A .txt file is nothing but bytes. Nothing in it says whether the byte 0xE9 means é on its own, or is the first half of a two-byte sequence meaning something else entirely. Whatever program opens the file has to guess, and different programs guess differently — which is why the same file can look perfect in one editor and be full of question marks in the next.
Guessing wrong destroys characters rather than merely displaying them oddly. Reading a Windows-1252 file as UTF-8 replaces every byte it cannot understand with U+FFFD, the “replacement character”. In a 31-character test line containing é, ü, curly quotes, an em dash and a pound sign, eight characters were destroyed outright — and the conversion still reports success.
This tool reads the byte-order mark when the file has one, tests whether the bytes form valid UTF-8 when it does not — legacy bytes almost never do — and falls back to Windows-1252, which cannot fail because all 256 of its byte values mean something. The result line names the encoding it used, so a wrong guess is visible rather than silent.
What the mangled characters are telling you
If your document opened with strings like these in it, the file was UTF-8 and something read it as Windows-1252. Each pair below was produced by actually encoding the character and decoding those bytes the wrong way, not from memory.
| What you see | What it should be |
|---|---|
| é | é (e-acute) |
| è | è (e-grave) |
| ü | ü (u-umlaut) |
| ñ | ñ (n-tilde) |
| ç | ç (c-cedilla) |
| á | á (a-acute) |
| — | — (em dash) |
| – | – (en dash) |
| “ | “ (opening curly quote) |
| ‘ | ‘ (opening single quote) |
| ’ | ’ (apostrophe) |
| £ | £ (pound sign) |
| € | € (euro sign) |
| … | … (ellipsis) |
| ° | ° (degree sign) |
| • | • (bullet) |
A capital A with a hat, or a capital A with a tilde, in front of an odd symbol is the signature of this direction. The opposite mistake — a Windows-1252 file read as UTF-8 — looks different: every affected character collapses into the same black diamond or a plain question mark, because the information is gone rather than misread.
Why this happens to your files and not to everyone's
Plain ASCII survives everything. If your text is English with straight quotes and no accents, every encoding agrees on every byte and nothing can go wrong. The moment a name carries an accent, or a word processor turned your quotes into curly ones, the file leaves the range the encodings agree on.
Where the file came from decides which encoding it is. Windows Notepad saved new files as ANSI — in practice Windows-1252 — until Windows 10 version 1903 in 2019 changed the default to UTF-8. Files written before that change, files from older Windows machines, and text exported by desktop software on Windows are the ones most likely to be Windows-1252. Anything produced on the web, on macOS or on Linux is almost certainly UTF-8.
You can check without any tool. Open the file in Notepad and look at the status bar, which names the encoding on current versions of Windows. Or convert it here and read the encoding on the result line — it says read as UTF-8 or read as Windows-1252 next to the paragraph count.
Every line becomes its own paragraph — and when that is wrong
A Word paragraph is a unit of text that reflows: make the window narrower and the words rearrange themselves. A line in a text file is not that — it ends where somebody pressed Enter, or where a program broke it at 72 or 80 characters.
For text written as normal prose, one line per paragraph is exactly right. For a hard-wrapped file — an old email, a README, anything from Project Gutenberg — it is wrong in a way you only see later: every wrapped line becomes a separate paragraph, so the document will not reflow, justification looks ragged, and printing gives you a page of short stubs.
The fix takes a second and belongs before the conversion, not after. In any editor with regular-expression search, replace a newline that is not followed by a blank line with a space, so wrapped lines rejoin and real paragraph breaks survive. Then convert.
What you actually get, and what a .docx is
A .docx is a ZIP archive containing XML. Rename one to .zip, open it, and you will find word/document.xml holding your text inside markup. That is why this conversion can run in a browser with no server: it is a matter of writing correct XML and zipping it, not of understanding a proprietary binary format.
The document uses your word processor's own default style on an A4 page with one-inch margins. Nothing is imposed — no font, no size, no colour — so applying a style afterwards takes one click rather than a fight. Tabs become real tab stops and blank lines stay blank.
Nothing is invented, either. A line in capitals does not become a heading, and a line starting with a dash does not become a bullet, because guessing wrong about that is worse than leaving it alone. If your text is Markdown and you want those to become real headings and lists, convert it as Markdown instead.
If you wanted a PDF rather than a Word file
The TXT to PDF tool does that in one step, with one real limitation worth knowing before you pick it: a PDF has to carry its own fonts, and that tool uses the standard built-in Helvetica, which covers Latin script only. Text in Devanagari, Tamil, Chinese, Cyrillic, Arabic or emoji will not render.
A Word document has the opposite property — it stores the text and lets whatever opens it choose the fonts — so every script survives. If your text is not purely Latin, convert to Word first and export to PDF from there, or use Word to PDF afterwards.
For tabular data the answer is different again: a .csv is plain text too, and has exactly the same encoding problem, so CSV to Excel applies the same detection rather than assuming UTF-8.
Frequently asked questions
- Why does my converted document show é instead of é?
- The file is UTF-8 and something read it as Windows-1252. The table above lists the common ones. Converting here fixes it, because the bytes are tested for valid UTF-8 before any fallback is used — nothing is guessed when it can be proved.
- Why did my accented characters turn into question marks or black diamonds?
- That is the opposite mistake: a Windows-1252 file read as UTF-8. It is more serious, because every unreadable byte is replaced by a single marker character and the original is gone. Convert from the original file rather than from the already-damaged copy.
- Does the Word file keep my formatting?
- A .txt file has no formatting to keep — no bold, no headings, no fonts, only characters and line breaks. You get those characters in a clean document using your word processor's default style, which is the most faithful result possible.
- Will Hindi, Chinese, Arabic or emoji survive?
- Yes. A Word document stores the text and lets the program that opens it supply the fonts, so every script converts cleanly. This is the main reason to choose Word over PDF for non-Latin text.
- Is the .docx a real Word file?
- Yes — it is standard Office Open XML, the same format Word itself writes, and it opens in Microsoft Word, Google Docs, Apple Pages and LibreOffice. It is not a renamed .txt or an .rtf.
- Is my file uploaded anywhere?
- No. The document is assembled by JavaScript in this page and the ZIP is built in your browser. Your text never leaves your device, so there is nothing for Filesvo to store or to read.