Rohman
Someone on Google's own support forum put it better than I could: "Google Drive thinks my 150 page PDF OCR file only has 55 pages."
No error. No warning banner. No note at the bottom of the document saying the rest was skipped. You right-click, choose Open with Google Docs, get a document back, and it looks like it worked. The tail of your file is simply gone, and you find out when you go looking for something on page 80.
Google Drive's free OCR is genuinely useful and costs nothing, which is why so many people reach for it. It also has two hard limits that Google documents in a support-page table almost nobody reads, and both of them fail silently.
The Two Limits
2 MB per file. That is the whole ceiling. A ten-page color scan at 300 DPI runs 5 to 15 MB, so the limit rules out most real scans before you start. There is no paid tier that lifts it inside Drive and no official workaround — Google's answer is to make the file smaller.
The first ten pages of a PDF. Everything past page ten is dropped, quietly, with no marker in the output. This is the one that costs people real work, because a truncated document looks exactly like a complete one until you audit it.
Neither limit is a bug. Both are documented behaviour. What is missing is any signal at the moment it happens, and a 55-page result from a 150-page input is the kind of failure you carry forward for weeks before noticing.
The workarounds are what you would expect and about as pleasant. Compress the PDF until it slips under 2 MB, accepting whatever that does to the image quality your OCR then has to read. Or split the file into ten-page chunks, run each one by hand, and paste fifteen Google Docs back together. There is no batch mode. Every file needs its own right-click.
Drive Already Read It
Here is the part most people have not clocked.
Google Drive runs text extraction on your uploaded PDFs and images regardless of whether you ask for OCR. It does this to build its search index, which is why Drive search can find a word inside a scanned PDF that you cannot select or copy a single character from. The recognition already happened. The Google Doc conversion is a separate, manual step that hands you a copy of what Drive extracted for itself the moment the file landed.
That reframes the privacy question. It is not "should I run OCR on Google's servers" — the upload was the decision. Everything after it is bookkeeping.
What "Automated Systems" Covers on a Free Account
Google's privacy policy says plainly that it collects the content you create, upload, or receive, and that it uses "automated systems that analyze your content" to provide tailored features. Google does not sell your files and says it does not target ads based on Drive content. Those are real commitments and worth crediting.
The gap that matters is between account types, and it is wider than most people assume.
On a paid Workspace account, Google's contractual language is specific: your data is not reviewed by humans or used for generative AI model training outside your domain without permission, admins can set a policy that keeps customer data out of model improvement entirely, and the whole thing sits behind SOC 2 and the ISO 27001/27017/27018 certifications.
On a free consumer account, you get the general privacy policy. Content may be processed to improve services and develop new products and features. If you have opted into Gemini features, Google collects prompts and generated content and may use it to develop machine-learning technologies. Where "improving services" ends and "training models" begins is not a line a consumer account gets to draw.
For a scanned recipe, none of this matters. For the documents people actually run OCR on, it might. Free Google Drive is not HIPAA-compliant, which is a problem for medical records. Attorney-client privileged material sitting on a third party's servers is a conversation you may not want to have. Tax returns, bank statements, passport scans and driver's licences are the exact document classes that end up in an OCR queue, and they are the exact ones where the upload is the risk rather than the processing.
There is a small irony worth noting: Google Cloud's own Sensitive Data Protection service uses OCR to detect sensitive data inside stored documents. The capability to read what you uploaded is not hypothetical. It is a product.
The Free One Is the Weakest of Google's Four
Google sells four different OCR products, and the one in Drive is the oldest and simplest pipeline of the set.
Google Docs OCR is free and built into Drive. Google Lens handles camera and screen capture. Cloud Vision API costs $1.50 per thousand units after a free monthly allowance. Document AI runs $1.50 to $30 per thousand pages for structured extraction. The accuracy numbers people quote for "Google OCR" almost always come from Cloud Vision, not from the free Drive feature — so the reputation is borrowed from a product you are not using.
The free pipeline's weak spots are documented by Google itself. Lists, tables, columns, footnotes and endnotes are "not likely to be detected." In practice tables collapse into linear text, multi-column layouts merge into one paragraph, headers and footers mix into the body, and page numbers land inline mid-sentence. Handwriting is the worst case; Google's own guidance calls its free OCR the least reliable of its options on handwritten input.
Developers hitting Drive OCR through the API have watched it get squeezed too. One report from Google's developer forums: "even when limiting myself to only 1 file, I nearly always encounter a GoogleJsonResponseException saying 'User rate limit exceeded'." The free path is being deprioritised in favour of the metered ones.
The Accuracy Gap Is Narrower Than the Privacy Gap
The assumption doing the most work in people's tool choices is that cloud OCR is meaningfully more accurate. On clean printed text, it barely is.
An independent benchmark across 100 real-world images measured character error rates on clean print at 0.6% for Google Cloud Vision and 1.2% for Tesseract running in a browser. On a 500-page legal scan, another test put Google Cloud Vision at 98.4% character accuracy and Tesseract 5 at 96.2% — roughly 40 errors per page against 95.
That difference is real, and on clean documents it is small enough that the upload is doing most of the work in the trade. Where cloud engines pull genuinely ahead is handwriting: 8.2% character error rate for Cloud Vision against 23% for browser Tesseract, which is the difference between usable and not. If your document is handwritten, a cloud engine or a vision model is the honest answer.
For everything else — printed contracts, invoices, scanned reports, forms — resolution matters far more than which engine reads them. Tesseract on a clean 300 DPI scan clears 99%. The same engine on a 100 DPI scan drops to 88–93%. Fixing your capture is worth more than switching vendors, which is the whole argument of why your phone photos read as garbage.
OCR With No Page Cap and No Upload
OCR PDF runs recognition in your browser. The file is never uploaded, so there is no 2 MB ceiling, no ten-page truncation, no rate limit, and no account.
- Drop in the PDF or image — any size your browser can hold
- Pick the language rather than hoping auto-detect guesses right
- Run recognition across every page, not the first ten
- Download a searchable PDF with the text layer written in, or send it to Word
If the sceptical read is "everyone claims privacy," that claim is checkable here in a way a policy page never is. Open DevTools, watch the Network tab, run the OCR. No request carries your file. That is the difference between an architecture and a promise.
One thing worth doing first: check the orientation. Recognition accuracy collapses on sideways pages and Drive does not auto-rotate at all — it requires the document to arrive right side up. Straighten the pages, then recognise. It is the cheapest accuracy gain available, and it works no matter whose engine reads the file.
