Drop your PDF into the emerald zone below and get a spreadsheet back. Columns are found by measuring where text repeatedly starts across rows, so a table arrives as a real grid rather than as one long string per line. The printed lines around a table are ignored entirely, which is why a report that draws no borders converts just as well as one that boxes every cell. Numbers land as numbers you can total. Nothing is uploaded.
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 now. The guide below explains how column detection actually works - because a PDF does not know it contains a table - what the sensitivity control changes, when to reach for it, why some numbers stay text on purpose, and how to tell in advance whether your file will convert cleanly.
Two minutes, nothing to install, no account for your first run. This PDF to Excel converter executes inside the page you are reading, so every step below happens on your machine.
Click the drop zone above or drag the file anywhere onto this page. Each PDF is parsed as it lands, and the card that appears shows its page count with a preview of page one, so you can confirm you picked the right file. Nothing is transmitted at any point.
Detect columns is the default and is what you want for any table. It finds the horizontal positions where text repeatedly starts across many rows and splits each line on those, which is why it works on a table that draws no borders at all. Switch to One line per row only when the page is prose. Check the column count afterwards.
One sheet per page keeps each page separate and is right when the pages hold different tables. All in one stacks every page into a single sheet with a blank row between them, which is right when one table runs across twelve pages.
Press Convert to Excel and the work happens on your processor. The result screen tells you how many columns it detected, and comparing that against the columns you can count in the PDF is the fastest check available. If the number is wrong, change the sensitivity one step and run it again. It is the only control here.
One fact governs everything else. A PDF does not know it contains a table. It holds no cells, no rows, no columns and no grid, only a stream of instructions saying paint these glyphs at these coordinates. The ruled lines you can see around a table, when there are any, are separate drawing instructions with no recorded relationship to the text inside them. That has a consequence people find backwards: ruled lines buy you nothing here, and a table drawn with nothing but aligned whitespace converts just as well as a fully boxed one. A printed invoice with a border around every cell, and a plain column of figures separated only by spaces, are the same problem to this tool, because in both cases the only usable evidence is where the characters sit. Most exported reports draw no borders at all.
So extracting a table means inferring it back from geometry alone. The algorithm has three stages and each one exists to fix a specific failure of the naive approach.
Every glyph run on the page is collected with its position and rendered size. Runs sharing a baseline become one line, with a tolerance proportional to the type size rather than a fixed number of points, because a fixed tolerance either merges two lines of 8 point footnotes or splits a 30 point heading containing a superscript.
Within a line, the gap between one fragment and the next is measured. A small gap is a word space. A gap wider than about one em is a cell boundary, because inside a cell text is set with word spacing and between cells it is set with column spacing, and those differ by an order of magnitude.
Most simple extractors stop here. It is not enough, because cell boundaries found line by line drift: a row whose second column happens to hold a short value has a wider gap, so its split lands somewhere different from the row above it. The columns do not line up, and you get a grid that looks correct until you scroll.
This stage makes it work. In a genuine table, text starts at the same horizontal position row after row. Every cell start position from every line on the page is collected, sorted, and clustered with a tolerance. A cluster that recurs on enough rows is a column. A cluster appearing on one row out of eighty is a stray, and it is discarded before it can push a whole column sideways and ruin every row beneath it.
Each cell is then assigned to its nearest confirmed column, rather than to wherever its own line happened to split. That is what makes row four line up with row forty. Nothing is dropped. If two fragments land in the same column they are joined, never overwritten, because losing a value silently is worse than a slightly wide cell you can see and fix.
A page of ordinary prose produces exactly one cluster, so it comes back as one column, which is the correct answer for prose. The algorithm never has to be told whether the page contains a table at all.
Verify the privacy claim in thirty seconds. Load this page, disconnect from the internet completely, then convert a PDF. It still works, because there is no server-side step for it to depend on, and no converter that uploads your statement could survive the same test.
Everything else here has a sensible default. This one you will change occasionally. It sets how far apart two start positions can be and still be counted as the same column, which is the single number the whole clustering stage turns on.
| Setting | What it does | Reach for it when |
|---|---|---|
| Tight | Positions must be within about five points to be treated as one column. Finds more columns. | Two real columns keep arriving merged into one cell. Common in dense financial tables with narrow columns. |
| Normal | About nine points. The default, and correct for the large majority of documents. | Start here every time. |
| Loose | About sixteen points. Merges near columns. | One real column keeps arriving split in two. Common when a column contains a mix of right-aligned numbers and left-aligned text, which produces two apparent start positions. |
The result screen prints the column count. That number is the fastest diagnostic available, so compare it against the columns you can count by eye in the PDF itself. Too low and you go tighter, too high and you go looser. Change it one step at a time, and you will rarely need more than a single adjustment to get a grid whose columns line up all the way down.
Switch to One line per row when the page is prose, or when a table is so irregular that no consistent column positions exist anywhere on it. You get one cell per line. That sounds unhelpful, and on an awkward document it is the fastest route out: the Text to Columns feature built into Excel, or a few minutes of manual splitting, beats fighting an extractor that has nothing consistent to work with.
The other awkward case is a merged cell spanning several columns, typically a section heading sitting inside the table. It lands in the column nearest its start position, which is usually the first, and that is generally what you want, because a heading sitting in column A is easy to spot and easy to merge back. A row of totals under a table behaves the same way. One click fixes it.
A spreadsheet where every cell is text is a spreadsheet you cannot sum, sort or chart. So values that are genuinely numbers get written into the workbook as numbers. Eagerness here destroys data. The rule is deliberately conservative, and anything ambiguous stays as text rather than being guessed at and silently changed into something you can never get back.
A value becomes a number only if it is a plain integer or decimal, optionally with thousands separators, optionally negative. These five kinds of value stay text on purpose:
| Value | Stays text because | What eager conversion would do |
|---|---|---|
| 00123 | It has a leading zero, so it is an identifier rather than a quantity. | Turn a part code into 123 and break every lookup against it. |
| +48 123 456 789 | It starts with a plus sign. | Treat a phone number as an arithmetic expression. |
| 2024-0417 | It is not a plain number. | Guess it is a date and convert an invoice reference into 17 April. |
| 9781234567897 | It is more than fifteen digits. | Exceed the precision a spreadsheet can hold and silently round the last digits off an ISBN. |
| GBP 1,204.50 | It contains a currency symbol. | Nothing safe. Strip the symbol in Excel afterwards if you want the number. |
Ambiguous stays text. Text can always be converted to a number in Excel in a single operation, using either a paste-special multiply by one or a Text to Columns pass. A number that has silently lost its leading zeros cannot be recovered at all, because the information is gone from the file.
Switch the option off entirely if you are extracting a table of identifiers, which is the right call for a product catalog, a serial number list, or an inventory export where every column is a code.
The first row of each sheet is treated as a header by default: set bold, shaded, and frozen so that it stays visible while you scroll. Freezing matters most. Reading row 350 of a four hundred row extraction with no column names anywhere in sight is exactly how people end up misreading a number by an entire column. Switch it off for a table that has no header row.
The output is a real .xlsx, not a CSV with a misleading extension and not an HTML table renamed. It is a ZIP package containing SpreadsheetML, and it opens natively in Microsoft Excel, LibreOffice Calc, Google Sheets, Numbers and the mobile Office apps.
Cells are written as inline strings rather than through a shared string table. A shared table is a deduplication optimization: it stores each distinct piece of text once and has every cell reference it by index. On a normal spreadsheet that saves real space. On extracted PDF text, where nearly every cell is unique, it saves nothing measurable and adds an entire class of index-mismatch failure that produces a workbook full of the wrong words. Inline strings are equally valid OOXML and every spreadsheet application reads them.
A scanned PDF is a photograph of a page wrapped in a PDF container. No characters. Only pixels arranged so that a human eye reads them as digits and letters, which leaves the converter with nothing at all to put in the cells.
A converter that silently hands back an empty workbook is doing the worst possible thing, because you believe it worked. This one checks the text layer and stops with a plain explanation when there is nothing in it.
Open the PDF and try to select a row of the table with your mouse. Text highlights? You have a text layer, and extraction will work. If nothing highlights it is a scan, and no amount of column detection will help you, because there are no columns of text there to detect in the first place.
The fix is optical character recognition, which reads the letterforms off the picture and welds a real text layer onto the PDF. Convert the searchable PDF that produces and extraction works normally. One caveat: recognition on a table is harder than recognition on prose, because a skewed scan produces column positions that drift steadily down the page, and drifting positions are exactly what defeats the clustering stage. Straighten the scan first if you can.
Check whether an original exists before converting anything. If the PDF came out of a system that can also export CSV, use that instead. Bank portals, accounting packages, shop platforms and analytics tools nearly all offer one, and a native export beats the best extraction in the world every time. Ask first. It costs nothing.
Consider what people convert in this direction. Bank statements, and the supplier price lists that arrive under NDA. Payroll summaries. Customer lists coming out of a system that has no export button anywhere in it. Invoice registers for a VAT return. This is the most commercially sensitive tool in the whole suite, by a distance, and it is the one where a careless upload would cost you the most.
The usual architecture is an upload form in front of a queue and an extraction process on somebody's server. Every one of those documents crossed the internet and was written to a disk you do not control, retained for a period you cannot verify.
This converter has no upload endpoint, because there is no server-side step for one to feed. Your PDF is opened with the browser File API, parsed by JavaScript on your processor, and the workbook is assembled in memory and handed back as a Blob your own browser downloads from itself. No queue. No temporary link. The file exists on your disk and in your RAM, and nowhere else.
For a business handling personal data, this stops being a preference. Uploading a customer list to a free web converter is a transfer to a third party processor, and it is a transfer nobody documented, assessed or agreed to. Running the conversion on the machine the file already sits on removes the transfer entirely. That is a different legal position.
| Symptom | Cause | Fix |
|---|---|---|
| This PDF has no text layer | It is a scan. There are no characters to extract. | Run OCR on it first, then convert the searchable PDF that produces. |
| Everything landed in column A | Fewer than two columns were confirmed, so the page was treated as prose. | Set sensitivity to Tight. If that fails, the table probably has no consistent column positions and One line per row plus Text to Columns is faster. |
| Two columns merged into one cell | The gap between them is narrower than the sensitivity tolerance. | Set sensitivity to Tight. |
| One column split into two | The column mixes left-aligned text and right-aligned numbers, creating two start positions. | Set sensitivity to Loose. |
| Rows are offset from each other | Usually a skewed OCR scan whose baselines drift across the page. | Straighten the scan and re-run OCR. Drifting positions defeat the clustering stage. |
| Numbers arrived as text | They carry a currency symbol, a leading zero, a plus sign or more than fifteen digits. | Deliberate, and explained above. Strip the symbol in Excel and multiply by one, or use Text to Columns. |
| A header spans several columns | A merged heading cell lands in the column nearest its start position. | Expected. Merge it back in Excel, which is one click. |
| Column headers repeat mid-sheet | The table repeated its header on every page of the PDF and you chose All in one. | Switch to One sheet per page, or delete the repeats with a filter in Excel. |
No. The conversion runs in your browser on your own processor, and the PDF is never transmitted anywhere. Confirm it yourself in thirty seconds. Load this page, disconnect from the internet entirely, and convert anyway: it still works, because there is no server-side step for it to depend on. That matters more here than anywhere else in the suite, because the documents people convert to a spreadsheet are bank statements, payroll summaries and customer lists.
By measuring where the text sits, never by looking for the printed lines. In a real table, text starts at the same horizontal position row after row, so every cell start position on the page is collected, sorted and clustered. A position recurring on enough rows becomes a confirmed column, and one appearing on a single row is discarded as a stray. Each cell is then assigned to its nearest confirmed column rather than to wherever its own line happened to split, which is what makes row four line up with row forty. Borders are irrelevant. A table that draws none converts exactly as well as one that boxes every cell.
Because fewer than two column positions were confirmed, so the page was treated as prose. For prose that is the correct answer. If the page really is a table, set Column sensitivity to Tight and run it again. If that still fails, the table has no consistent column positions, which happens with heavily merged or hand-formatted layouts, and One line per row followed by Text to Columns in Excel will be faster than fighting it.
Yes, when they are unambiguously numbers: plain integers and decimals, optionally with thousands separators, optionally negative. Values with a leading zero, a plus sign, a currency symbol or more than fifteen digits deliberately stay text, because a part code turned into a number has lost its leading zeros permanently and a phone number is not an arithmetic expression. Text can always be converted to a number in Excel afterwards. A silently mangled identifier cannot be recovered.
Because the PDF is a scan: a picture of a page, with no characters in it to put into cells. The conversion stops and says so rather than handing you an empty workbook. Test it by trying to select a row of the table with your mouse. If nothing highlights, it is a scan. Run optical character recognition on it first, then convert the searchable PDF that produces, and straighten the scan before you do if it went through the feeder crooked.
Yes. It is a genuine .xlsx ZIP package containing SpreadsheetML, not a CSV with a misleading extension and not a renamed HTML table. It opens natively in Microsoft Excel, LibreOffice Calc, Google Sheets, Numbers and the mobile Office apps, with column widths set from the content and the header row frozen.
Yes, and it is the default. Each page becomes its own sheet, named after the page and after the source file when you convert several PDFs at once. Switch to All in one to stack every page into a single sheet with a blank row between them, which is what you want when one table runs across twelve pages of a report.
Choose All in one and the pages are stacked into a single sheet in order. If the table repeated its column headers on every page of the PDF, those repeats will appear part way down the sheet; filter them out in Excel, which takes seconds. One sheet per page keeps them separate instead. Your call.
A merged cell, typically a section heading spanning the width of a table, lands in the column nearest its start position, which is usually the first. That is generally what you want, and merging it back in Excel is one click. Reconstructing merge ranges from geometry is guesswork. Guessing wrong produces a grid that is harder to fix than one which is simply flat.
Almost always because the column mixes left-aligned text with right-aligned numbers, which produces two distinct start positions on the page and therefore two separate clusters where you wanted one. Set Column sensitivity to Loose and they merge. The opposite problem, two real columns arriving as one cell, is fixed by setting it to Tight instead. Change it one step at a time. Check the column count after each run.
No. The author, producer, creation date and any custom fields the originating system wrote are not copied, because the workbook is assembled from the extracted text rather than derived from the source file. The .xlsx carries a title, a creation timestamp and a producer string, and nothing else.
Yes. Drop them all in and each contributes its pages to the workbook, with sheet names carrying the source file name so you can tell them apart. The batch limits are 20 files and 100 MB for anonymous visitors and free accounts, and 100 files and 500 MB on CartHacker Premium. An operation is one conversion run, however many files or pages went into it.
No watermark, no logo, no trial banner, no attribution required, and the output is free for commercial use. No row limit either. A very large extraction is bounded by the memory in your own machine rather than by any policy of ours, and a 20,000 row table will strain a phone tab long before it troubles a desktop. Anonymous visitors get one operation per 12 hours, a free CartHacker account gets two, and CartHacker Premium removes the counter entirely.
Ask for the CSV. Every time one exists. A native export from the system that produced the PDF is exact, and no extraction from geometry can ever beat it. Bank portals, accounting packages, shop platforms and analytics tools nearly all offer one. Use this tool for the case where no export exists at all: a supplier price list that only ever arrives as a PDF, a report from a system nobody administers any more, or a document somebody emailed you and cannot resend.
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.