Google Vision vs Space OCR

Google Cloud Vision is excellent raw OCR. Its TEXT_DETECTION and DOCUMENT_TEXT_DETECTION features return the full text plus a fullTextAnnotation organized as Pages › Blocks › Paragraphs › Words › Symbols, each carrying a boundingPoly and a recognition confidence. If you want every word and where it sits, Vision is a mature, scalable choice.

But there's a distinction people hit on day two: Cloud Vision returns text and geometry, not structured key-value fields. It will tell you the string Invoice No. INV-4471 is on the page, and the pixel box around each word — but it won't hand you { invoice_number: "INV-4471" }. That structured extraction is Google Document AI, a separate, processor-based product (Form Parser, the pretrained Invoice parser, and so on), which you create and configure per processor.

This guide is a fair comparison: where Vision (and Document AI) is the better choice, and where space-ocr fits — and it leads with a live demo you can check rather than a feature grid you have to trust.

Proof first: an extraction you can check

The one thing most OCR vendors won't put in front of you is an extraction where every value points back to the exact spot on the page it came from. Hover any field below — the box on the receipt is where that value was read, and each value carries a match ratio for how much of its characters were actually located on the page.

What actually differs

Vision and space-ocr both read documents and return coordinates, so a feature checkbox grid hides the real differences. They are: what shape of output you get (raw text vs. named fields), what kind of per-value score (recognition confidence vs. character coverage), which coordinate system the boxes live in, and how much you have to assemble yourself. Every cell below is a verified fact for each product — use it as a checklist against your own workload.

Recognition confidence vs. character coverage

This is the subtlest line in the table, so it's worth being precise. Cloud Vision documents a recognition confidence — defined verbatim for a block as "Confidence of the OCR results on the block. Range [0, 1]." — present at every level from Page down to Symbol. It's the model's self-reported certainty that it read the glyphs correctly. That's genuinely useful, and it's exactly what a raw-OCR engine should expose.

space-ocr's match_ratio answers a different question: of the characters in the extracted value, how many were actually found among the symbols on the page? It's a coverage measure, not a self-assessment — at or above 0.85 the value is treated as a confident vision_symbol_match; below that it's flagged low_confidence. Neither number is "better"; they tell you different things. To be fair to Vision: it documents a recognition confidence, not that it can't character-match — space-ocr simply makes character coverage the contract for each structured value.

Coordinates: pixels-of-this-exact-image vs. a normalized grid

Vision's boundingPoly vertices are in the original image's scale — pixel coordinates of the bytes you uploaded. That's precise, but it ties every box to that exact file: resize, recompress, or mishandle EXIF rotation and your overlays drift. There's even a serialization gotcha — when a vertex's x or y is 0 it is omitted from the JSON (a 100×100 full-image poly serializes as [{}, {"x":100}, {"x":100,"y":100}, {"y":100}]), so naive overlay code has to backfill those zeros.

space-ocr returns a bbox of integers { xmin, ymin, xmax, ymax } on a 0–1000 normalized grid (0,0 top-left, 1000,1000 bottom-right), independent of the pixel dimensions. Convert when you actually render: pixel_x = bbox_x / 1000 * image_width. It also returns four ordered vertices (tl/tr/br/bl) for an oriented box that follows a tilted phone photo, and EXIF orientation is applied on load so the returned coordinates match the image you display.

That one request returns named fields — no fullTextAnnotation to parse into key-value pairs, and no separate Document AI processor to create. Each value comes back with a bbox on the 0–1000 grid, four oriented vertices, a match_ratio, and a bbox_source. For the full coordinate model see an OCR API with bounding boxes; for receipts and invoices specifically see the invoice data extraction API guide. If AWS is your other option, there's also an Amazon Textract alternative write-up.

Where Google Vision (or Document AI) is the better choice

A fair comparison names where the incumbent wins. Reach for Google when:

• You need massive-scale raw OCR — every word and symbol with geometry — and you'll do the structuring downstream yourself.
• You're already deep in Google Cloud and want OCR that drops into your existing project, billing, IAM, and storage.
• Your structured-extraction needs are met by Document AI's processors — Form Parser, the pretrained Invoice/W2/ID processors, or a custom Document AI extractor trained on your own document types.

If that's you, Google is a strong fit and an alternative buys you little.

Where space-ocr fits instead

space-ocr earns its place when one or more of these matters:

• You want structured fields from one HTTP call — not raw text you parse, and not a separate processor to create and configure. Send an image, get named fields back inline.
• You want to verify, not just trust a recognition score. Every value returns with its on-page box and a match_ratio for character coverage, and clicking a cell highlights exactly where it was read.
• You want coordinates that survive resizing. A 0–1000 normalized grid plus oriented vertices, with EXIF handled on load — no pixel boxes glued to one exact file.
• You don't want to stand up storage. Results land in a sheet you can query server-side (GET /view) and export to CSV in one click — no database.
• You build with Claude. A two-line Claude Code plugin and a dependency-free Python client.

The whole call is one HTTPS request. The engine takes raster images (JPEG, PNG, GIF, BMP, TIFF, WebP); in the web app you can drop a PDF and each page is converted to an image first.

How to try space-ocr alongside Cloud Vision