How to OCR an Image with Python: Extracting Text from Photos and Scans via API

#api #python #ocr #tutorial

Someone on your team just photographed a whiteboard after a planning meeting, or a customer emailed a phone snapshot of a handwritten delivery note, or a field technician uploaded a picture of a nameplate riveted to a machine. In every case, the information you need is sitting inside a JPEG, not a PDF, and not a single word of it is selectable, searchable, or usable by any downstream system. It's pixels pretending to be data.

This is a narrower problem than "OCR a PDF," and it deserves its own answer instead of a workaround. A scanned PDF at least has a predictable container. A photo does not: it might be rotated, poorly lit, slightly blurred, or shot at an angle, and it arrives as a raw image file, not a document format with pages and metadata. PDF4me's Image Extract Text endpoint runs OCR directly against that image, no PDF conversion step in between.

The endpoint, exactly as documented

POST /api/v2/ImageExtractText against the base URL https://api.pdf4me.com. The request body, confirmed against the live docs page, is exactly two fields:

{
  "docName": "receipt.jpg",
  "docContent": "<base64-encoded image bytes>"
}

docName is the source filename, extension included (that's how the service knows what format it's looking at). docContent is the full image, Base64-encoded. The documented supported formats are JPG, PNG, BMP, TIFF, and other popular image formats.

One honest flag here: the docs page's own JSON response example shows a generic "File Content" placeholder field rather than a fully worked example of the extracted-text payload shape. Treat the exact response field name as something to confirm against your own first live call (the API Tester below is the fastest way to do that) rather than something this article can promise down to the key name.

A working Python example

The shape of the call is simple: read the file, Base64-encode it, POST the JSON payload, and check the response status before trusting the body.

import base64
import requests

API_KEY = "YOUR_API_KEY"  # from your PDF4me developer dashboard
ENDPOINT = "https://api.pdf4me.com/api/v2/ImageExtractText"

with open("receipt.jpg", "rb") as f:
    image_bytes = f.read()

payload = {
    "docName": "receipt.jpg",
    "docContent": base64.b64encode(image_bytes).decode("utf-8")
}

headers = {
    "Content-Type": "application/json",
    # Check docs.pdf4me.com / your API dashboard for the exact
    # Authorization header scheme (e.g. Basic vs Bearer) tied to your key
    "Authorization": API_KEY
}

response = requests.post(ENDPOINT, headers=headers, json=payload)
response.raise_for_status()

result = response.json()
print(result)

Wrap this the way you'd wrap any external API call in production: check response.status_code before you trust the body, log the filename alongside the request so a failure is traceable back to a specific image, and decide up front what "no text found" should mean for your pipeline versus what an outright request failure should mean. A blank whiteboard photographed by mistake and a malformed payload are two very different situations, and code that treats them the same way will make the wrong call on whichever one happens first in production.

The PDF4me API v2 documentation for Image Extract Text lists working code samples across Python, C#, Java, JavaScript, and several no-code/serverless environments (Salesforce, Google Apps Script, AWS Lambda) alongside n8n, so whichever stack you're standardized on, there's a real starting point.

Why the image itself is the real variable

Every OCR system is only as good as the image you feed it. Resolution and focus matter more than almost anything else, a crisp scan and a motion-blurred phone photo of the same page are not the same input. Orientation is a silent failure mode too: a photo taken sideways doesn't throw an error, it just returns garbage, because the engine is reading pixels, not intent. If your app accepts photos from a phone, normalize orientation using the image's own EXIF data before OCR, not after you're debugging why extraction quality dropped.

Where this fits, and where it doesn't yet

As of this writing, Image Extract Text has a documented, ready-made action in n8n (supporting JPEG, PNG, GIF, and BMP up to 50MB, with both JSON and plain-text output shapes), but no dedicated Power Automate, Zapier, or Make page of its own. If your stack is one of those three, the REST endpoint above is callable from any of their generic HTTP-request actions today, it just isn't wrapped in a purpose-built connector step yet.

Before wiring this into anything, validate your payload shape with the API Tester, and use the Connect to PDF4me API guide to get your API key and first authenticated call working.

What this doesn't solve

OCR is pattern recognition against pixels, not comprehension. It will hand you back the characters it's confident it saw, it will not tell you that the total on a receipt looks wrong or that the text is in a language your downstream system doesn't expect. Build your validation logic to expect imperfect input, especially on low-quality or handwritten source images, rather than treating extracted text as ground truth the moment it arrives.

Website: pdf4me.com
Documentation: docs.pdf4me.com
Developer portal: dev.pdf4me.com

DEV Community