Convert any document to Markdown

Every format it handles

Eighteen of them, and six are ones you will struggle to find anywhere else — subtitles, notebooks, email, LaTeX, decks and ebooks. Those are exactly the things people feed to an AI and then discover no converter supports.

Documents

PDF is the format people ask for most and the one that converts worst — and that is the format's fault rather than the converter's. A PDF is positioned glyphs on a page: there is no marker anywhere in the file saying "this is a heading". Word records what things are; PDF only records where they sit. So headings here are inferred from font size relative to the body text, which works well on reports and papers and less well on anything designed.

Two consequences worth knowing before you try. A scanned PDF contains no text at all — it is a picture of a document — so nothing can be extracted from it without OCR, which this tool deliberately does not do. It will say so rather than hand you an empty box, which is more than most converters manage. And multi-column layouts can interleave, because a PDF stores the order glyphs were drawn rather than the order a human reads them; that case is flagged when it is detected. The parser is Mozilla's pdf.js, and it is fetched only when you actually convert a PDF, so no other format pays for its 1.3MB.

Word (.docx) is the highest-fidelity conversion here, because Word records structure rather than appearance: a heading is tagged as a heading, a list item as a list item, a table as a table. All three survive exactly. Images are dropped, since Markdown cannot embed them and they are not text a model can read.

OpenDocument (.odt) behaves the same way and for the same reason — it stores an explicit outline level on every heading, so LibreOffice and Google Docs exports come through with their hierarchy intact.

PowerPoint (.pptx) becomes one section per slide, in order, with the first line of each slide treated as its title and the rest as bullets. Speaker notes are left out — they are a different document, and mixing them into the slide text makes a deck read as though it contradicts itself. Handing a model a deck is a common thing to want and almost no converter offers it.

EPUB is unzipped and each chapter converted in reading order, split by horizontal rules. Worth knowing before you try: a whole book will not fit in any model's context window, so this is for extracting a few chapters rather than feeding in a novel.

Email (.eml) pulls the headers you actually care about — from, to, date, subject — into a block at the top, decodes quoted-printable and base64 bodies, and converts HTML mail rather than dumping its markup. Quoted reply history is kept but counted, so you are told how much of what you are about to send is old.

LaTeX (.tex) recovers sectioning, bold, italic, lists, code blocks and links, and passes maths through untouched because models read $...$ perfectly well. Tabular environments are left alone and flagged — they do not map cleanly, and a mangled table is worse than an obvious one.

RTF works but is the weakest of the document formats, and that is the format's fault rather than the converter's: RTF records how text looked, not what it was, so headings and lists usually arrive as plain paragraphs.

Spreadsheets and data

Excel (.xlsx) reads the shared-string table properly, so text cells come through as text rather than as the numeric indexes they are stored as. Every sheet becomes its own section. This is the conversion with the largest quality gap against pasting raw: a model reading a pipe table can tell which column a value belongs to on every single row, and reading raw CSV it frequently cannot.

CSV and TSV get the delimiter sniffed rather than assumed, and quoted fields are parsed properly — a cell containing a comma, or an escaped quote inside a quoted string, is the normal case rather than an edge case.

JSON is inspected before it is converted. An array of flat objects is a table in disguise and is rendered as one; anything nested becomes headings and nested lists instead. YAML is converted structurally into a nested list, and says so — it is not a full YAML implementation, so anchors and multi-line scalars may not survive.

Jupyter notebooks (.ipynb) keep markdown cells as prose and code cells inside fenced blocks tagged with the kernel language. Cell outputs are included but truncated: a notebook that printed a ten-thousand-row dataframe would otherwise bury the actual code under noise you are paying tokens for.

Transcripts and the web

Subtitles (.srt and .vtt) get the treatment that makes them useful rather than merely converted. Cue numbers and timestamps are stripped — they are most of the file and pure cost once you are reading the words — and the fragments are rejoined into flowing prose, split at sentence ends. That is what you want when the real task is "summarise this meeting" or "what did they decide".

HTML has its furniture removed first: navigation, headers, footers, sidebars, forms, scripts and anything marked aria-hidden. On a real article that is most of the bytes, and it is where the saving figure above comes from. What survives becomes headings, lists, links, tables and code blocks.

Plain text is the one people expect to do nothing, so it earns its place by finding the structure that is already there: underlined headings, SHOUTED section titles, bullet characters people actually type, and bare URLs. It reports what it found, and tells you plainly when there was nothing to change — a converter that hands your file back silently is indistinguishable from a broken one.

Why Markdown rather than plain text

A model does not read files, it reads text — so the only question that matters is which representation survives tokenising with its meaning intact. Markdown wins on both counts. Models are trained on enormous amounts of it, so headings, lists, code fences and tables carry structure the model actually uses, and it costs barely more than the raw words.

The clearest case is tabular data. Fifty rows of raw CSV reads noticeably worse to a model than the same fifty rows as a pipe table, because the table makes the column a row belongs to unambiguous on every line. That is why spreadsheets here become tables rather than comma-separated lines.

The anti-pattern is pasting raw HTML. A page's markup is mostly <div class="css-1x7y"> — it costs tokens on every single tag and carries nothing a model can use. Stripping it is where most of the saving on this page comes from.

Why it converts instantly

Most document converters upload your file to a server, wait behind whatever else is in the queue, process it there, then send the result back down the wire. That round trip — not the parsing itself — is where the seconds go on every "upload and wait" tool.

This one skips the round trip entirely. Every format here, including the ZIP-based ones (DOCX, XLSX, PPTX, EPUB, ODT), is decoded by your browser's own engine using the native decompression it already ships with. There is no server anywhere in the conversion path, so there is nothing to queue behind and nothing to wait on. The time shown above is the real number for whatever you just converted, not a marketing figure — it will usually read in milliseconds.

PDF is the one honest exception. The first PDF you convert in a session fetches a parsing library — a one-time cost that typically finishes in a few hundred milliseconds. Every PDF after that reuses it, and every other format never needed it at all.

Why nothing is uploaded

Every conversion on this page runs inside your browser. There is no upload, no server-side copy, and nothing to log — not as a policy we ask you to trust, but because the bytes never leave your device in the first place.

That matters more here than on most tools. The documents people want to hand an AI are contracts, board packs, medical notes, interview transcripts and internal decks. A converter that quietly posts those to a server is asking for a level of trust it has no way to earn. This one does not need to.

Questions

Is there a file size limit?

Only what your browser can hold in memory, which is far more than a context window can take anyway. The practical limit arrives long before the technical one: a 200-page document converts fine and then will not fit in any model.

Why does the converted text sometimes lose formatting?

It depends on how much structure the original actually carried. Word and OpenDocument mark their headings explicitly, so those survive exactly. RTF barely marks anything, and PDF marks nothing at all — headings there have to be inferred. Each format's page says what survives and what does not.

Can I convert several files at once?

One at a time for now. Converting a batch and pasting all of it usually means exceeding the context window, which the token panel above will tell you the moment it happens.

What do I do if it is too long for my model?

Split it, or summarise the parts you do not need in full. The fit line above names the smallest model your text still fits in, so you can see immediately whether the problem is the document or the model you picked.

Are my files uploaded anywhere?

No. Every format is parsed inside your browser and the file never leaves your device. Nothing is uploaded, stored or logged, which is why this tool can accept contracts, transcripts and internal documents at all.

Why is this faster than other converters?

Because there is no server in the conversion path to be slow. A converter that uploads your file has to send it out, wait in a queue, process it, then send the result back — that round trip is most of what you are waiting on. This one parses the file on your own device the moment you drop it, so there is nothing to send and nothing to wait for. The time shown next to your result is the real measurement, not a claim.