# Google Docs OCR PDF: The Open-With Trick, Tested - Author: FastBankConvert (https://fastbankconvert.com) - Published: 2026-10-17 - Category: Google Sheets, Numbers and LibreOffice - Canonical: https://fastbankconvert.com/blog/google-docs-ocr-pdf > Use Google Docs OCR on a PDF by opening it with Docs from Drive: what it reads, why tables come out as text, and moving it into Sheets. To run Google Docs OCR on a PDF, upload the file to Google Drive, right-click it and choose Open with, then Google Docs. Docs builds a new document holding the text it recognised. Words and line breaks usually survive. Tables do not, so each statement row arrives as one line of text you still have to split into columns. ## How do you run Google Docs OCR on a PDF from Drive? Google Docs OCR has no button of its own. You reach it from Google Drive: right-click the PDF, pick Open with, then Google Docs. Drive then creates a separate Google Doc from the file and leaves the original PDF where it was. The whole job takes three clicks once the file is uploaded. The steps on a computer: 1. Open Google Drive in a browser and upload the PDF, or find it if it is already there. 2. Right-click the file. 3. Choose **Open with**, then **Google Docs**. 4. Wait for the new document to open in a tab. Its name matches the PDF. Google's own help page, [Convert PDF and photo files to text](https://support.google.com/drive/answer/176692), lists the conditions. The file should be 2 MB or smaller. It can be a multipage PDF or a JPEG, PNG or GIF photo. The page gives no maximum page count, but the 2 MB ceiling is the limit most scanned statements hit first, because a scan stores every page as a picture. If the Open with menu does not show Google Docs, check the file type. A file renamed to end in .pdf that is really something else will not convert. A PDF inside a ZIP archive has to be extracted first. ## Page elements Google Docs OCR keeps and drops Google Docs OCR keeps the words and some of their styling, and it drops structure. Google's help page says bold, italics, font size, font type and line breaks are likely to be retained, while lists, tables, columns, footnotes and endnotes are not likely to be detected. For a bank statement, the structure is the part you wanted. Think of a statement page as three layers: - **Text.** Dates, merchant names, amounts and headings. These usually come through, one printed line per line of output. - **Layout.** The grid that tells you which amount belongs to which date. This is what gets lost. - **Decoration.** Logos, shaded bars, rules between rows. These vanish or turn into stray characters. What survives is therefore a reading of the page, top to bottom, with line breaks where the printer put them. That is enough for a letter or a receipt. For anything laid out in columns, plan on a second step to rebuild the grid. Header blocks on statements are a special case. An account summary often sits in a box beside the address block, so two unrelated pieces of text share the same height on the page. Docs may join them into one line, putting a balance in the middle of a street address. Read the first page of output with that in mind before you trust any figure from it. ## Why do PDF tables come out of Google Docs OCR as plain text? PDF tables come out of Google Docs OCR as plain text because the conversion reads characters and lines, not cells. A table on a page is only text placed at certain positions. Docs writes each row as one line, with spaces where the gaps were, and Google's help page says tables are not likely to be detected. On a statement, that means a printed row such as a date, a description, a withdrawal and a balance becomes a single string. The gaps between columns may turn into one space or several. Empty cells disappear entirely, so a row with a withdrawal and a row with a deposit can look the same once the column positions are gone. That last point causes the worst errors. If a statement has separate withdrawal and deposit columns, the position of the amount is the only thing that tells you its sign. After OCR, both rows read as "date, text, amount, balance". You have to work the sign out again, usually from the change in the running balance. Wrapped descriptions add a second problem. When a merchant name runs onto a second printed line, Docs gives that continuation its own line of output. It then looks like a row with no date and no amount, sitting between two real transactions. ## Moving Google Docs OCR text into Google Sheets columns To move Google Docs OCR text into Google Sheets, copy the transaction lines from the document, paste them into column A of a new sheet, and split them with Data, then Split text to columns. Splitting on spaces breaks descriptions into pieces, so the cleaner method is to replace the column gaps with one character you can split on. ### A worked example The three lines below are an example of what Docs might produce from a scanned checking statement. The values are made up. ``` 03/02 GROCERY MART #114 52.18 1,947.82 03/04 PAYROLL DEPOSIT ACME 1,250.00 3,197.82 03/05 CITY WATER UTIL 61.40 3,136.42 ``` Each line holds a date, a description, one amount and a balance. Pasting them into Sheets and splitting on spaces would cut "GROCERY MART #114" into three cells. A better order of work: 1. Paste the lines into column A. 2. In column B, pull the date with a formula that takes the first five characters, for example `=LEFT(A2,5)`. 3. Pull the last two numbers with a pattern match. [Splitting statement text into columns in Google Sheets](/blog/split-text-to-columns-in-google-sheets) walks through the separator choices and the formulas for this. 4. Treat whatever sits between the date and the first amount as the description. 5. Work out the sign from the balance. In the example, the balance rises from 1,947.82 to 3,197.82 on 03/04, so 1,250.00 is a deposit. It falls on 03/02 and 03/05, so those amounts are withdrawals. The resulting table, still example values: | Date | Description | Amount | Balance | | --- | --- | --- | --- | | 03/02 | GROCERY MART #114 | -52.18 | 1,947.82 | | 03/04 | PAYROLL DEPOSIT ACME | 1,250.00 | 3,197.82 | | 03/05 | CITY WATER UTIL | -61.40 | 3,136.42 | Check every row the same way: the previous balance plus the signed amount should equal the balance on the row. A row that fails points to a misread digit or a missing line. If your source is a photo rather than a PDF, the same Docs route works, and [getting an image into Google Sheets](/blog/image-to-google-sheets) compares it with the other ways to turn a picture of a table into rows. ## Scans that Google Docs OCR misreads: size, rotation and faint print Google Docs OCR misreads scans that are too small, turned sideways, or low in contrast. Google's help page asks for text at least 10 pixels high, pages right side up, common fonts such as Arial, and sharp images with even lighting. A statement photographed at an angle on a kitchen table fails most of these. Run through this checklist before you upload a scan: - **File size.** At 2 MB or under. If the scan is larger, split it into fewer pages per file, or rescan at a lower resolution that still keeps small print legible. - **Orientation.** Every page right side up. A landscape page saved sideways reads as noise. - **Text height.** The smallest print, often the amount column, at least 10 pixels tall in the image. - **Contrast.** Black text on a light page, no shadow across one side, no glare on glossy paper. - **One page per image.** For photos, no second page peeking in at the edge. - **Flat paper.** A curled page bends the lines, and bent lines merge with their neighbours. Two symptoms tell you a scan failed. An empty or nearly empty document means Docs found no text it could read. A document full of runs of odd letters means it found shapes but could not match them. In both cases, fixing the scan beats fixing the output. Watch digits in particular. OCR on any engine tends to swap 5 and S, 0 and O, and 1 and l when print is faint. A description with a wrong letter is easy to spot. An amount with a wrong digit looks normal, which is why the balance check in the worked example matters. ## When a statement PDF should skip the Google Docs OCR route Skip the Google Docs OCR route when the PDF already has selectable text, when it runs past a few pages, or when the amounts must be right without checking each one. Docs is a free way to pull words off a scan. It does not rebuild tables, so every statement costs you the splitting and sign work afterwards. Test whether you need OCR at all. Open the PDF in any viewer and try to select a word in the transaction list. If it highlights, the file has a text layer, and copying the text, or using a converter that reads that layer, gives cleaner results than OCR of the same page. Docs is also a poor fit when: - **The file is over 2 MB** and splitting it would mean a dozen separate documents to stitch together. - **The statement has separate debit and credit columns**, so every sign has to be rebuilt from the balance. - **You convert statements every month.** The manual steps repeat each time. - **The data is sensitive** and you would rather not leave a copy in Drive. Delete the generated Doc when you finish if you do use it. For those cases, a converter that keeps the column positions saves the rebuilding. [What a drag-and-drop PDF converter does with your file](/blog/drag-and-drop-pdf-converter) explains how that kind of tool handles an upload. FastBankConvert is one such tool for bank statements: it is being built to return dates, descriptions, amounts and balances in separate columns, and to warn you before download if the balances do not add up. It is getting ready to open, and you can join at [Get started](/get-started).