Drop your PDF into the zone below and get back a Markdown file. Headings become hash-prefixed headings, bullet points become list items, and columns of figures become pipe tables a model can actually read. YAML front matter records which file it came from and how many pages it had, and page markers survive as HTML comments so a generated answer can cite page fourteen rather than gesturing at the document. Nothing is uploaded. A contract or a board pack never crosses the internet on its way into your pipeline.
Your files are read by JavaScript running on your own machine. There is no upload, no queue, and no copy on our server to delete later.
Drag a card to reorder it, or use the arrows under each card. The order here is the order in the output. Each card is a preview of the finished page, so what you see is what the PDF will contain.
Esc close ← → move R rotate
Starting
This is your processor doing the work, so the time it takes depends on your machine and not on how many other people are on the site.
The converter above is ready to use. The guide below is the part that matters if these files are going into a retrieval pipeline or a context window - why Markdown outperforms plain text for a language model, what structure is actually recoverable from a PDF, how tables survive the trip, and which of the settings on the right you should change before you convert a thousand documents rather than one.
Two minutes, nothing to install, and no account needed for your first run. This PDF to Markdown converter executes inside the page you are reading, so every step below happens on your machine and your documents are never transmitted anywhere - which is the entire reason it exists, given what people usually want to feed to a model.
Click the drop zone above or drag the files anywhere onto this page. Each document is parsed as it lands and the card shows its page count, so a file that is password protected or has no text layer reports it before you spend an operation on it.
GitHub Flavored Markdown has pipe tables and is what every current language model was trained on, so it is the right default for almost everything you are likely to convert. CommonMark has no table syntax. Tables become fenced blocks under it, so choose CommonMark only when the parser at the other end is strict about it.
For a retrieval pipeline, switch off Keep bold and italic. Emphasis inferred from a font name is noisy, and a chunker that splits on it produces worse matches. For a human reader, leave it on. Leave front matter and page markers on in both cases, because a chunk that cannot say which file and which page it came from cannot be cited.
Press Convert to Markdown and the work happens on your processor. Open the result and read the top of the file. Two things matter: whether the headings landed at sensible levels, and whether the first table came out as a pipe table rather than a paragraph of loose numbers. Those answers predict the whole batch.
Drop several PDFs at once and you get one .md per document by default, which is what a documentation folder or an ingestion directory wants. Switch on One file for the whole batch to concatenate them instead, which suits a set of chapters that were split apart and should be read as one thing.
The obvious way to get a PDF into a model is to extract its text and paste it. That works. It also throws away most of what made the document useful, and the loss is worth naming precisely, because it shows up later as wrong answers rather than as an error message anybody can see.
Markdown carries all four back at a cost of a handful of characters, and the choice of syntax is not arbitrary: every current large language model has seen an enormous quantity of Markdown in training, because it is the native format of README files, documentation sites, forum posts and issue trackers. A hash at the start of a line means heading to a model with no instruction, no schema and no examples. None are needed.
The consequences are direct. A chunker can split on heading boundaries, so a chunk is a section rather than a thousand characters. A pipe table survives into the context window with its rows and columns intact. And the page markers this converter writes let a generated answer cite page fourteen of the file it came from, which is the difference between a system people trust and one they check by hand.
Token economics, briefly. Markdown is not free. A heading costs two characters, a pipe table costs a few per row. Against that, structure lets a retriever return the right 500 tokens instead of the wrong 5,000, so the total spent per answer goes down rather than up. The only case where plain text genuinely wins is when the whole document fits in the window and you were going to send all of it regardless.
A PDF does not contain a document. It contains drawing instructions: set this font at this size, move to these coordinates, show these glyphs. There is no heading, no paragraph, no list and no table anywhere in the file. Those existed in whatever produced the PDF and were discarded at export, because a PDF records appearance exactly and achieves that by throwing every trace of structure away.
Every heading in your Markdown is therefore a conclusion drawn from geometry. Understanding how those conclusions are reached is what tells you which documents in your corpus will convert cleanly, and it takes two minutes.
Lines first. Positioned glyph runs are grouped into lines by baseline, with a tolerance proportional to type size rather than fixed - a fixed tolerance either merges two lines of eight point footnotes or splits one line of thirty point display type containing a superscript. Inside a line, the gaps between runs are measured. A gap above roughly a fifth of an em becomes a space, which matters because producers routinely emit adjacent words with no space character between them and the gap is the only evidence. A gap above a full em is recorded as a column boundary, and that single measurement is what makes table detection possible.
Paragraph boundaries come from three signals in descending order of reliability: a vertical gap noticeably larger than the running line pitch, measured per page rather than assumed; a line that stopped short of the right edge of its own text block, since the next line cannot then be a continuation of it; and a change of indentation. The right edge is measured per block rather than per page, because one wide table would otherwise declare every ordinary paragraph short.
Nothing in a PDF says "heading", so three measurements decide it between them. Type size is the primary signal. Body size is computed as the median size across the whole document weighted by character count, so a report carrying more footnote characters than paragraph characters still measures its body correctly, and any block set noticeably above that median becomes a candidate. Weight is the second, read from the font name the PDF embeds, since a producer writing Helvetica-Bold or Arial,Bold has declared the face and the weight travels with it. Block length is the third, and it acts as a veto: a block only slightly larger than the body must also be short to qualify, because a whole paragraph set one point up is emphasis rather than a title. The size ratio then picks the level. About 1.55 and above becomes #, 1.28 and above becomes ##, and anything smaller that still qualifies becomes ###. Ratios, never absolute point sizes, which is what lets the same thresholds work on a 9 point contract and a 14 point report without being told which is which.
List items are found by their marker. A leading bullet character - including the six different glyphs producers actually use for one, of which three are visually indistinguishable dashes - starts an unordered item. A leading number followed by a dot or a bracket starts an ordered one, and the number itself is read, so a list beginning at seven keeps its numbering instead of silently restarting at one. The marker character is stripped from the text, because it becomes list syntax in the output and leaving it in would print the bullet twice on every single item.
The one case nothing can fix. If your document was typeset at a single size throughout and its headings were made bold without being made bigger, there is nothing in the file distinguishing them. That information was destroyed at export. Any tool claiming to recover it is guessing, and a guessed heading structure is worse than none because a chunker will trust it.
One section of this page matters more than the rest. This is it. A table is where the difference between a good extraction and a bad one becomes the difference between a right answer and a wrong one, because a flattened table does not look broken. It looks like a list of numbers, and the model answers from it anyway.
Detection runs in two stages. First the converter finds runs of consecutive lines that all contain at least one column-sized gap, using the measurement taken during line building. Two or more such lines make a candidate region. Then the column detector examines only that region, finds the horizontal positions where text repeatedly starts across its rows, and splits there. The two-line minimum matters: a single line with a wide gap is usually a right-aligned page number or a leader-dotted contents entry, and promoting those would fill a clean export with junk tables.
The output is a GitHub pipe table. That means one line per row with cells separated by vertical bars, plus a second line of dashes and colons sitting directly under the header, which is what tells the parser where the header stops and how each column aligns. A header of | Quarter | Revenue | followed by | --- | ---: | gives you a right-aligned second column. Pipes inside cell text are escaped as \|, because a stray vertical bar is the one thing in Markdown that corrupts structure rather than appearance. Under CommonMark, which has no table syntax at all, the same data is written as a fenced block with tab-separated columns: readable, honest, and not pretending to be a table the parser cannot see.
| Table style | Result | Why |
|---|---|---|
| Financial statements, price lists, spec sheets | Excellent | Wide consistent gaps and short cells. This is the case the detector was built for. |
| Tables with ruled lines and generous padding | Very good | The padding makes the gaps. The ruled lines are never read - they are drawing operations, not structure. |
| Dense tables with tight columns | Mixed | Neighboring columns merge. Set Column sensitivity to Tight and convert again. |
| Cells whose text wraps onto several lines | Poor | Each wrapped line becomes a row, because nothing says the second line belongs to the cell above. |
| Merged and spanned cells | Not recovered | A span exists only as an absence of text at a coordinate. Reconstructing it would be guesswork. |
| Tables in a scanned page | Nothing | No text layer at all. Run OCR first, then convert what it produces. |
Column sensitivity is the one setting worth experimenting with before a large batch. Raise it to Loose when one real column keeps arriving split in two; lower it to Tight when two columns keep arriving merged. Convert one representative document at each of the three settings and read the tables that come out of each of the three runs. Do it once. Five minutes there decides the quality of a thousand files.
The defaults on this page are tuned for a person converting one document to read or edit. If you are converting a corpus for retrieval, three of them should change, and the reasons are worth stating.
The structure this produces is designed to be split on rather than through. A reasonable strategy that costs almost nothing to implement:
Why a browser-based converter matters here specifically. The documents people most want to put into a private model - contracts, board packs, medical records, tender responses, anything under NDA - are exactly the documents that must not be uploaded to a free converter to get there. There is no upload endpoint. The confidential document and the tool that reads it never occupy the same machine as anybody else.
Escaping in Markdown is a judgment call rather than a rule. Both directions are visible. Escape every special character and you produce text nobody can read and every downstream consumer has to undo. Escape nothing and a line beginning with a digit and a dot silently becomes a list, a product code containing an underscore turns half a paragraph italic, and a pipe inside a cell destroys a table.
The line drawn here is narrow: a character is escaped only where leaving it alone would change how the document parses, and everywhere else it survives exactly as the PDF wrote it. In practice that means three rules.
Emphasis is applied to the visible characters and never to the padding around them, because **bold **word is not bold in any parser worth targeting. A run whose text is entirely whitespace has its emphasis dropped, which is what stops a document full of stray asterisks. Adjacent runs with identical formatting are merged before serialization. Six runs, one word. A PDF text layer routinely emits one run per glyph cluster, so a single bold word can arrive as six separate runs, and writing those verbatim would produce a line of asterisks with letters scattered between them.
Fences grow when they have to. A code block whose content already contains three backticks is fenced with four. Trailing blank lines are collapsed to exactly one, because a file ending in a run of empty lines shows up as changed in every diff for the rest of its life.
The usual architecture for a PDF to Markdown converter is an upload form feeding a parser on somebody else's machine, and increasingly an API that sends your pages to a vision model for extraction. Both mean your document crossed the internet, was written to a disk you do not control, and in the second case was processed by an inference provider whose retention policy you did not read. For a public datasheet, fine. For the documents people actually want to put into a private model, it is the exact thing they were trying to avoid.
There is no upload endpoint here, because there is no server-side step. Your file is opened with the browser File API, parsed by a PDF engine running as JavaScript on your processor, and the Markdown is produced as a Blob your own browser downloads from itself. No queue. No temporary link. The document exists on your disk and in your RAM, and nowhere else.
One useful consequence. Because only the text layer is read, PDF metadata does not travel into the Markdown. The author name your word processor embedded, the internal file path in the title field, the software that produced it and any tracked revision information are all left behind. Converting to Markdown strips them as a side effect, which is usually what you want before a document enters a shared index.
Every file is probed as it lands, so a locked or damaged document reports at the drop zone rather than after the operation is claimed. What follows appears in the finished Markdown instead, and nearly every entry is a property of the source PDF rather than a setting you missed.
| Symptom | Cause | Fix |
|---|---|---|
| This PDF has no text layer | It is a scan. There are no characters in the file, only a picture of them. | Run OCR on it first, then convert the searchable PDF that produces. |
| No headings, everything is a paragraph | The document uses one type size throughout, so nothing distinguishes a heading. | Not recoverable from the file. If the corpus is large and uniform, a rule over the output text is more honest than a guess inside the converter. |
| A table came out as paragraphs | Columns too close for the gaps to register, or cells wrapping onto several lines. | Set Column sensitivity to Tight and convert again. If that fails, the geometry genuinely does not carry the structure. |
| Stray asterisks through the prose | Emphasis inferred from font names on a document that switches faces frequently. | Switch off Keep bold and italic. For a pipeline that is the right setting anyway. |
| Paragraphs split at every line | A narrow column where almost every line reaches the right margin, so the short-line signal never fires. | Common in two column academic layouts. Crop the columns apart first if it matters. |
| Words are joined together | The producer emitted adjacent runs with no space characters and gaps too small to read as spaces. | Typical of design software exports. A search and replace over the output is the practical fix. |
| Two column pages read interleaved | Reading order comes from geometry and a two column page has two vertical flows down one sheet. | Crop the columns apart before converting. Nothing in the file says which column comes first. |
| Ligatures came out as odd characters | The font maps fi and fl to single glyphs with no correct ToUnicode mapping. | A search and replace. It is a defect in how the PDF was written and every extractor hits it. |
| Headers and footers repeat every page | Running heads are real text on every page and there is no marker saying they are furniture. | Strip lines that repeat on more than half the pages with a script over the output. It is three lines of code and worth writing once. |
Drop the PDF into the zone at the top of this page, choose GitHub or CommonMark, and press Convert to Markdown. The conversion runs in your browser on your own processor, no account is needed for your first run, and the output has no watermark, no banner and no required attribution.
Because plain text destroys hierarchy, table relationships and list boundaries. Nothing warns you. A flattened table becomes a run of numbers whose columns are gone, so the model can see a figure but not which column and row it belonged to. Markdown restores all of it for a handful of characters, and every current model reads it natively because it was trained on enormous quantities of it.
Neither. The extraction and the Markdown generation run in your browser on your own processor, and your document is never transmitted anywhere. That matters more here than on most tools, because the files people want to feed to a private model are usually the exact files that must not be uploaded to a free converter to get there. You can confirm it by loading this page, disconnecting from the internet, and converting anyway.
Yes, into GitHub pipe tables with a header row and an alignment row, when the columns are separated by clear horizontal gaps. Gaps decide it. The converter finds runs of consecutive lines split by gaps wider than a full em, then finds the positions where text repeatedly starts across those rows. Financial statements, price lists and specification sheets convert very well. Dense tables merge neighboring columns unless you set Column sensitivity to Tight, and cells whose text wraps onto several lines become several rows.
GitHub Flavored Markdown has pipe table syntax and is what every current language model was trained on, which makes it the right default. Use GitHub unless you cannot. CommonMark has no table syntax at all, so under it tables are written as fenced blocks with tab-separated columns instead - readable and honest, rather than pipes that a strict parser renders as a paragraph full of vertical bars. Choose CommonMark only when the parser at the other end demands it.
No, switch it off. Emphasis here is inferred from a font name containing "bold" or "italic", which is a heuristic over an inconsistent signal, and in a chunker that treats punctuation as a boundary it produces measurably worse matches. Leave it on when a person is going to read or edit the file, where it is genuinely useful.
It records the source file name, the page count, the conversion date and the generator at the top of every file. Four lines, no more. A document that reaches a vector store six months from now with no record of where it came from is a document nobody can verify an answer against. It is the difference between a citable corpus and a pile of text.
Yes. Leave Mark page boundaries on. Each boundary is written as an HTML comment, which is invisible when the Markdown renders and preserved by every parser. Carry the nearest preceding page comment into each chunk's metadata and a generated answer can say which page of which document it came from, which is what makes a retrieval system checkable rather than merely plausible.
No, and it says so rather than handing you an empty file. A scan is a photograph of paper. There are no characters in it at all, so there is nothing for the structure detector to work with. Run OCR on it first to weld a real text layer onto the images, then convert the searchable PDF that produces and everything on this page applies normally.
Because the source document switches font faces frequently and the emphasis detector is following it. Switch off Keep bold and italic. Adjacent runs with identical formatting are already merged before writing, and whitespace-only runs have their emphasis dropped, so what remains is genuine face changes in a document that has a lot of them.
Yes. 20 files and 100 MB per batch for anonymous visitors and free accounts, and 100 files and 500 MB on CartHacker Premium. By default you get one .md per PDF, which is what an ingestion directory expects. Switch on One file for the whole batch to concatenate them instead, which suits a set of chapters that were split apart and should be read as one document. Anonymous visitors get one operation per 12 hours, a free account gets two, and CartHacker Premium removes the counter.
Strip them from the output with a short script that removes lines appearing on more than half the pages. Three lines of code. Running heads are real text drawn on every page and nothing in the file marks them as furniture, so no extractor can distinguish them from content without seeing the whole document at once. Repeated furniture is the single largest source of noise in a retrieval index built from PDFs, so write the stripper before a large batch rather than after it.
Only memory. An operation is one conversion run regardless of page count, so a two hundred page report counts once against your allowance. Very large documents are more comfortable converted in two batches, because the text layer of every page is held while structure is being inferred across the whole document.
All of these run the same way: your file is read by JavaScript on your own machine, the work happens on your processor, and the result is handed back to you as a download that never existed anywhere else.
Find the apps that slow your store down, by name and in milliseconds, then answer shoppers' doubts with trust badges under Add to cart. Both are free, with no card and no access to your store admin.
Paste any page and get its three Core Web Vitals, the apps costing time, like Klaviyo or Judge.me, and the Shopify or WooCommerce fix.
Show the promises that settle doubts, from free shipping to a money-back guarantee, right under the Add to cart button. One line in your theme.
Change the link after printing and count the scans. 5 tracked codes on a free account, static codes unlimited.
Anonymous visitors get one operation per 12 hours, per network address. That is not a sales tactic, it is the only lever we have: this tool runs on your processor, not ours, so the run itself earns us nothing. An account tells us who you are, and the ceiling goes up the moment you have one. Your allowance resets in 12 h.
No credit card, no trial period, no sales call. Join with Google, GitHub, Facebook or email.
Free accounts get two operations per 12 hours, and yours reset in 12 h. Waiting costs you nothing and is a completely reasonable choice. If PDF work is a weekly job rather than a one-off, the counter is the wrong tool for you and Premium takes it off the page.
Cancel anytime. Everything you have already produced stays yours either way.