File to Text Converter: Turn Any Document Into Clean, LLM-Ready Text

A file to text converter extracts the readable content from a document — PDF, Word, Excel, HTML, EPUB — into plain text you can paste anywhere, most usefully into an LLM. Convert File by Repo2Txt does this in your browser for free: drop a file, get a clean markdown file.

I built the converter after one too many rounds of copy-pasting from a PDF into Claude and spending ten minutes deleting page numbers, headers, and broken line wraps. The extraction step sounds trivial. Done badly, it quietly wrecks your LLM's answers; done well, it's invisible.

This guide covers which formats convert cleanly, what "clean" actually means, and three worked examples with real numbers.

Why do LLMs need plain text instead of the original file?

Because a model reads a stream of tokens, not a file format. A PDF stores text as positioned glyphs on a page — the ISO 32000 spec that defines PDF has no concept of "paragraph" — so what you see as flowing prose is, internally, coordinates and drawing instructions. A DOCX is a zip archive of XML files under the ECMA-376 standard. Neither is something you can paste into a chat box.

Even when a chat interface accepts file uploads, you're trusting its built-in extraction, which you can't see or fix. Converting to text yourself means you can inspect what the model will actually read, cut the junk, and check the token count before you spend context window on it.

The token math makes the case. Using the ~4-characters-per-token rule from OpenAI's tokenizer documentation, Claude's default 200,000-token context window (per Anthropic's docs) holds roughly 800 KB of clean text. A raw 4.8 MB PDF doesn't fit anywhere; its extracted 62 KB of actual prose fits with 90% of the window left over.

Which file formats can be converted to text?

Almost anything that contains readable content, though formats differ in how much structure survives. Here's what Convert File by Repo2Txt handles, by family:

PDF documents

The hardest format, because PDFs store layout, not structure. Good extraction reconstructs reading order, joins lines broken by page width, and drops repeating headers, footers, and page numbers. Scanned PDFs are the exception — they're images of text, and need OCR rather than extraction.

Word documents (DOCX)

The friendliest format. Since DOCX is structured XML underneath, headings, lists, and tables map cleanly to markdown. A converted contract keeps its clause numbering and heading hierarchy, which matters when you ask an LLM to reference "Section 4.2."

Excel and CSV (XLSX, CSV, TSV)

Spreadsheets convert to delimited rows. The catch is volume: cells are dense, and a sheet you skim in seconds can be six figures of tokens. Trimming to the columns you need before converting matters more here than in any other format.

Presentations (PPTX)

Slides flatten to per-slide text blocks: titles, bullets, and speaker notes. Diagrams and SmartArt don't survive — if the argument lives in a diagram, expect to summarize it yourself.

Web and markup (HTML, XML, JSON)

HTML converts well when the extractor strips navigation, cookie banners, and scripts, keeping the article content. JSON and XML are already text; conversion here means pretty-printing and optionally flattening structure for readability.

Ebooks (EPUB)

EPUBs are zipped HTML under the hood, so chapters extract cleanly with headings intact. Useful for feeding a reference book chapter to a model alongside your question.

What does "clean" extraction actually mean?

The difference between usable and garbage output is boilerplate. Naive extraction of a 90-page PDF gives you the title and page number repeated 90 times, hyphen-broken words at every line wrap, and footnote markers scattered mid-sentence. Every one of those artifacts is noise the model has to read around, and you pay tokens for all of it.

Clean extraction means three things. Reading order is correct, including across multi-column layouts. Repeating furniture — headers, footers, page numbers, watermark text — is stripped. And structure that carries meaning (headings, list nesting, table rows) is preserved, ideally as markdown, because models handle ## Section and | cell | conventions natively.

Most online converters stop at "we got the characters out." The gap shows up later, as an LLM confidently citing a page header as if it were a finding.

Three worked examples with real numbers

I ran three typical files through Convert File and measured before and after:

Two lessons from the table. First, file size predicts almost nothing — the "big" 4.8 MB PDF produced the least text, because most of its bytes were embedded images and fonts. Second, spreadsheets are the token trap: that unassuming XLSX produced 8x as many tokens as the 90-page report.

The spreadsheet fix is column selection. Keeping only the four columns my question actually involved (date, region, product, revenue), cut the output to 38,000 tokens — the difference between the sheet dominating a Claude context window and leaving 80% of it free for analysis.

How to convert any file to text online (step by step)

1. Open repo2txt.com/convert-file in your browser. No account, no signup — the tool is free, and processing happens instantly. For contracts and internal reports, that's the property to check in any converter before you use it.

2. Drop in the file. PDF, DOCX, PPTX, XLSX, CSV, HTML, EPUB, JSON, XML, and other common formats are supported.

3. Pick plain text or markdown output. Choose Markdown when the document has a structure you'll want the LLM to navigate—headings, tables, lists.

4. Skim the output. 30 seconds of scanning catches the two failure modes worth catching: a scanned PDF that produces near-empty output, or a spreadsheet that produces far more than you need.

5. Copy it, check the token estimate, and paste it into your LLM with your question at the end.

The same clean-text principle extends past single documents. Entire codebases convert the same way with the GitHub repo to text converter, and folders on disk with the local folder to text converter — browser-side processing, same no-upload architecture.

How do you convert documents to plain text for AI without losing meaning?

Three habits that consistently improve what the model gives back:

Prefer markdown output for structured documents. A contract converted to a flat layout loses the visual hierarchy that tells a reader that clause 4.2 sits under Section 4. Markdown headings carry that hierarchy into the prompt, and answers that cite the right section follow.

Convert selectively, not completely. If your question concerns a single chapter, sheet, or section, convert it. Models reason better over 15,000 relevant tokens than 130,000 mostly irrelevant ones, and you leave room for the conversation.

Put the document before the question. Paste the converted text first, then ask. Long-context models weight the end of a prompt most heavily, so the question lands where it gets the most attention.

FAQ

Is there a file to text converter free no signup?

Yes. Convert File by Repo2Txt is free, requires no account, and runs in your browser. Drop in a PDF, DOCX, XLSX, PPTX, HTML, or EPUB file and copy the clean text or markdown output. Because processing is browser-based rather than server-side, it also works for documents you wouldn't upload to a random website.

Which file formats can be converted to text?

Any format that stores readable content: PDF, Word (DOCX), PowerPoint (PPTX), Excel (XLSX), CSV, HTML, EPUB, JSON, and XML all convert. Quality varies by format — DOCX and EPUB keep structure well, PDFs need careful extraction to fix reading order and strip page furniture, and scanned PDFs need OCR because they contain images of text, not text.

Why convert documents to plain text for AI instead of uploading the file?

Converting first lets you see and control exactly what the model reads. You can strip boilerplate, trim a spreadsheet to relevant columns, and check the token count against your model's context window before pasting. Uploading the raw file hands those decisions to the chat interface's hidden extraction, which you can't inspect or correct.

How many tokens does a converted document produce?

Estimate about 250 tokens per KB of extracted text, using the ~4-characters-per-token rule. In my tests, a 90-page PDF report produced 15,500 tokens and a 28-page contract 10,200 — both easily inside Claude's 200,000-token window. Spreadsheets run far larger: a 5,000-row sheet hit 130,000 tokens until trimmed to relevant columns.

Does converting a PDF to text keep tables and headings?

Headings survive when the converter outputs markdown; tables survive as pipe-delimited rows if they're real text tables rather than embedded images. What doesn't survive: charts, diagrams, and anything scanned. If a table is extracted scrambled, it was likely an image in the source PDF, and no text extractor can recover it without OCR.