A screenshot, an exported picture, a HEIC from a phone — into a spreadsheet, with the recognition running on your own device.
Quick answer:
Two steps, both in your browser. Convert the picture with image to PDF, then drop that into the table extractor with Read scanned pages (OCR) ticked. PNG, JPG, WebP, AVIF, GIF, BMP and iPhone HEIC all work; SVG does not, because it is a vector drawing whose text you can usually just copy. A screenshot is the best input this route gets — no lens, no lighting, no rotation — and enlarging the view before you capture is the single most effective way to improve it. Nothing is uploaded at either step.
How do I convert an image of a table?
Two steps, both in your browser: convert the picture with image to PDF, then extract it with Read scanned pages (OCR) ticked.
Which formats work?
PNG, JPG, WebP, AVIF, GIF, BMP and iPhone HEIC. Not SVG — that is a vector drawing rather than a picture, and its text is usually selectable, so copy it directly.
Is a screenshot better than a scan?
Yes, and it is the best input this route gets: pixel-exact, no lens, no lighting, no rotation. Enlarge the view before you capture, because character size matters more than anything else.
Why are some numbers wrong?
Because recognition confuses shapes that look alike — 0 with O, 1 with l, 5 with S. In a money column that gives a well-formed number that is simply the wrong one, so check the figures.
Is there a better route than a picture?
Yes, often. If the table is on a web page, select and copy it. If you have the original PDF, use that. Any export, even a rough CSV, beats a perfect recognition because nothing was inferred.
Both steps run in your browser. No account, no upload.
Two steps, and the first one is the bit people miss
Turn the image into a PDF.Image to PDF takes a JPG, PNG, WebP, GIF, BMP, AVIF or iPhone HEIC and writes a PDF — in your browser, like everything else here. You can put several images on one page, which is the quick way to do a batch.
Extract with recognition on. Drop that PDF into the table extractor, tick Read scanned pages (OCR), and press Extract tables.
The reason for the detour is worth a sentence: the extractor's whole job is finding columns in a page, and a page is what it takes. Wrapping the image is a few seconds and nothing is lost in it — the picture is embedded as-is, not re-encoded down.
If what you want is the words rather than a grid, image to text reads a picture directly and hands back text.
A screenshot is the best input this route ever gets
Better than a scan, and much better than a photograph. Worth understanding, because it tells you how to produce one.
A screenshot is a pixel-exact copy of what was rendered. There is no lens, no lighting, no paper. Nothing is rotated by half a degree, no shadow falls across a column, the background is uniformly white and the characters were drawn by the same font-rendering engine that draws them for reading. Everything that degrades a scan is simply absent.
What that means in practice: if your source is on screen — a dashboard, a report in a viewer, a web table, an application you cannot export from — screenshot it rather than printing and scanning it. Scale matters more than anything else. Enlarge the view before you capture (most applications zoom with Ctrl and +) so the characters are physically larger in pixels. Our rendering sweep shows the shape of that: cells exactly right ran 91% at 1× and 100% at 2.1×, and a screenshot taken at 200% zoom gives the recogniser that head start for free.
The other easy win is cropping. Take the table and not the whole window — a toolbar, a sidebar and a status bar are all text at coordinates, and they arrive as rows.
The formats, and one that behaves differently
Source
Works
Worth knowing
PNG screenshot
Best case
Lossless, so characters keep their exact edges. Default on Windows, Mac and most phones.
JPG screenshot or export
Fine
Lossy compression softens character edges slightly. Not usually enough to matter at a sensible size.
WebP / AVIF
Yes
Common from web pages now; converted on the way into the PDF.
HEIC from an iPhone
Yes
Decoded in the browser. Often arrives with no file type set at all, which is handled.
GIF / BMP
Yes
Mostly older screenshots and clipboard saves.
SVG
No
A vector drawing, not a picture. If the table is in an SVG the text is usually selectable — copy it directly.
A very small image is the one genuine failure. Recognition needs pixels per character, and a table screenshotted at phone width and then shared through a chat app — which re-compresses it — can arrive with characters only a few pixels tall. Nothing downstream recovers that. Recapture it larger if you can.
What comes back, and what to check
The columns are the reliable part. Across every quality we tested on a five-column table, all five columns came back — including from inputs far worse than any screenshot. Individual characters are the fragile part, and the classic error is a digit read as a letter.
Cells that cannot be what their column is are marked ⚠ before you download: a money column holding 12O0.00 is an impossible cell, not a doubtful one. That check flagged 6 of 6 deliberately corrupted figures with no false alarms, and raised nothing at all on 6 correctly extracted typed pages. It catches roughly one error in five overall — most of the rest sit in text columns where there is nothing to check a word against — so a page with no marks is not a page with no errors.
Double-click any cell in the preview to correct it while the picture is still in front of you. The edit goes into the download and the extraction underneath is untouched, so changing format or sheet settings afterwards keeps it.
When there is a better route than a picture
Recognising an image is a fallback, not a first choice. If any of these apply, take them instead — the result is exact rather than inferred:
The table is on a web page. Select it and copy; a spreadsheet reads the HTML off the clipboard and puts it in cells. No recognition, no errors.
You have the PDF the image came from. Use it directly — a software-generated PDF carries real characters and, if the table is ruled, real geometry too.
The application has an export. Even a rough CSV export beats a perfect recognition, because nothing was inferred.
The image is a screenshot of a spreadsheet. Ask whoever sent it for the file. This happens more than it should.
Where none of those exist — a supplier's portal with no export, a system you have read-only access to, a report that only ever arrives as a picture — this route is the one that works, and it works without your data leaving the machine.
Several images at once
Put them all on one page in image to PDF — it lays images out in a grid, several per page — then extract once. If each image holds its own table, use ✂ Choose table to take them one at a time, since the extractor will otherwise try to read a page of separate tables as one grid.
For a set of images that each contain the same table continuing — screenshots of a long list, page by page — put them in order, one per page, and choose Merge matching tables so they become a single sheet with the headings kept once.
Where to go next
Photo to Excel — the same route for a photograph of paper, where the capture matters far more than anything afterwards.
PDF to Excel OCR — how the recognition works and what its measured limits are.
Receipt to Excel — if the picture is a receipt, which has its own traps — the date-and-time line especially.
Frequently Asked Questions
Two steps, both in your browser. Convert the image to a PDF with image to PDF, then drop that into the PDF table extractor with Read scanned pages (OCR) ticked. The characters are recognised on your device and laid out into columns. Nothing is uploaded at either step.
Yes, and a screenshot is the best input this route gets — pixel-exact, no lens, no lighting, no rotation, no paper. Two things improve it further: enlarge the view before you capture, since bigger characters recognise better (91% of cells exact at 1× against 100% at 2.1× in our sweep), and crop to the table so a toolbar or sidebar does not arrive as extra rows.
PNG, JPG, WebP, AVIF, GIF, BMP and iPhone HEIC. PNG is the best case because it is lossless and character edges stay crisp; JPG is fine at a sensible size. SVG is the exception — it is a vector drawing rather than a picture, and its text is usually selectable, so copy it directly instead.
Because the extractor's job is finding columns in a page, and a page is what it takes. The wrapping step takes a few seconds and loses nothing — the picture is embedded as it is, not re-encoded down. It also lets you put several images on one page and extract them in one pass.
Recapture it larger. Recognition needs pixels per character, and a table screenshotted at phone width and then re-compressed by a chat app can arrive with characters only a few pixels tall — nothing downstream recovers that. Zooming the source before capturing is the single most effective fix.
Often, yes, and it is worth checking first because the result is exact rather than inferred. If the table is on a web page, select and copy it — a spreadsheet reads the HTML off the clipboard. If you have the original PDF, use that directly. If the application has any export at all, even a rough CSV, take it. Recognition is the route for when none of those exists.
Yes. Put them all on one page in image to PDF, which lays images out in a grid, then extract once. If each image holds its own table use Choose table to take them one at a time; if they are screenshots of one long list continuing, put them in order one per page and choose Merge matching tables so they become a single sheet.
No, at either step. The conversion to PDF and the recognition both run in your browser. The only network request is the recognition engine itself, about 6 MB the first time, which your browser then caches. Cells that cannot be what their column is are marked before you download — that check flagged 6 of 6 deliberately corrupted figures with no false alarms.
Yes. Convert the JPG to a PDF with image to PDF, then extract with Read scanned pages ticked. JPG is fine as a source; its compression softens character edges slightly, which matters only if the image is already small. PNG is the better format where you have the choice, because it is lossless.
Usually, with one caveat that catches people out: chat apps re-compress images, sometimes heavily, and a table screenshotted at phone width and then compressed can arrive with characters only a few pixels tall. Nothing downstream recovers that. Ask the sender for the original file — or better, for whatever they screenshotted.
Yes — the source format and the output format are independent. Once the image is extracted, set Format to CSV. JSON is there too if the table is going into code rather than a spreadsheet.
Because recognition confuses shapes that look alike — 0 with O, 1 with l, 5 with S, 8 with B — and in a money column that produces a well-formed number that is simply the wrong one. Cells that cannot be what their column is are flagged, but a misread that still looks like a number cannot be caught from the cell alone. Check the figures, and capture larger next time: character size is the single biggest factor.
Yes. If they are pages of one long list, put them in order one per page in image to PDF and choose Merge matching tables, and they become a single sheet with the headings kept once. If each image holds a different table, put them all on one page and use Choose table to take them one at a time.