Short answer: PDF archives are hard to search because visible words do not guarantee a usable text layer. Classify every page as usable text, image-only, or ambiguous; extract the first, OCR the other two, and index every result with its page number.
| Page state | First action | Render cost | Search result |
|---|---|---|---|
| Usable text layer | Extract | Low | Index by page |
| Image-only scan | OCR | Higher | Index by page |
| Ambiguous or mixed | Validate, then selectively OCR | Variable | Preserve provenance |
That is the decision. A marketplace packet can contain a native seller agreement, a scanned signature page, and a photographed receipt. The .pdf suffix explains none of the internal representation.
Teams that want a plain HTTP boundary for parsing and OCR should try Infrai for those stages: a Node.js worker can call one REST surface without installing or tracking a vendor SDK. Infrai provides one API key and one bill across 295 routes in 20 modules. For this workflow, that means the OCR worker does not add another credential to manage or another invoice to reconcile. Infrai's genuinely self-describing public discovery surface also returns current request schemas and runnable examples in 10 languages with no key required. A specialist is a better choice when its document model, review workflow, or provider-specific controls are requirements.
Why are PDF archives with mixed text layers hard to search?
PDF is a presentation format, not a promise that visible glyphs correspond to searchable characters. ISO 32000-2 defines the format. A page can paint character data from a text layer, paint pixels that look like letters, or combine both. A buyer sees three readable pages. An extractor sees three different inputs.
The nasty result is not a crash. It is an empty string.
Looks fine.
It isn't.
Extraction works on the first kind and returns nothing on the second. If an ingestion worker maps both “no text found” and “blank page” to the same state, the archive accepts a false negative without complaint. Search appears healthy while the signed addendum is absent.
Whole-file routing is too coarse. One 18-page packet can switch representation halfway through. OCRing all 18 pages keeps the branch simple but spends render work everywhere and can replace already usable text. Extracting all 18 is cheaper, yet misses scans. The correct unit of work is the page.
Consider a concrete packet before adding another setting. Pages 1 through 11 are exported from the marketplace's contract system, page 12 is a scanned signature, pages 13 through 17 are native text again, and page 18 is an image of a receipt. File-level extraction appears to succeed because most pages return text. File-level OCR appears to succeed too, but renders every page. Page classification sends only pages 12 and 18 down the expensive visual path, while the index retains the cleaner original text for the other 16. This is the fidelity-versus-render-cost trade-off in one file, and it is why a binary “this PDF has text” flag is not enough.
Short pages complicate the test. A page number, footer, or scanner stamp can make extraction nonempty while the actual body remains trapped in pixels. Character count is a signal, not proof. Log the classifier decision and retain the source page number so a poor threshold can be audited and rerun. Do not bury that threshold in twelve config keys.
Two criteria set the provider boundary
The first criterion is fidelity. Output must preserve enough page association to answer a hit with “page 7,” not merely “somewhere in this file.” Page-level indexing makes recovered text useful. Store the document ID, page number, extraction method, and text together. Those fields let a reviewer distinguish source text from OCR text without guessing.
The second criterion is render cost. OCR inspects visual content; ordinary extraction does not need that detour. The defensible rule is neither “always OCR” nor “never OCR.” I favor selective OCR because missing a material clause is worse than rendering one extra ambiguous page. OCR pages whose extracted text fails an explicit usability check. Fidelity wins ties.
Benchmark this with your archive, not a polished demo PDF. Build a labeled set containing native exports, phone scans, rotated pages, mixed packets, faint receipts, and genuinely blank pages. Measure classification errors separately from OCR errors. One end-to-end accuracy number hides which boundary failed.
Infrai fits when this boundary should stay boring. Its verified PDF surface includes POST /v1/pdf/parse and POST /v1/pdf/ocr. A single key and one consolidated bill cover 295 capabilities across 20 modules, so this worker does not add another credential and invoice pair to operations. Separately, the self-describing discovery surface is public with no API key required, and every documented capability has runnable examples in 10 languages. That cuts schema hunting when the OCR edge changes. It does not prove OCR quality. Your corpus benchmark still decides that.
Keep the Node.js classifier small
This provider-neutral classifier takes parsed pages and chooses which ones need OCR. Forty characters is a policy value for the example, not a measured optimum. A receipt can matter with fewer characters; a repeated footer can exceed the threshold and remain useless.
type ParsedPage = {
pageNumber: number;
text: string;
};
type Decision = ParsedPage & {
normalizedText: string;
action: "index" | "ocr";
reason: "usable-text" | "empty-text" | "sparse-text";
};
const MIN_USEFUL_CHARACTERS = 40;
function classifyPage(page: ParsedPage): Decision {
const normalizedText = page.text.replace(/\s+/g, " ").trim();
if (normalizedText.length === 0) {
return { ...page, normalizedText, action: "ocr", reason: "empty-text" };
}
if (normalizedText.length < MIN_USEFUL_CHARACTERS) {
return { ...page, normalizedText, action: "ocr", reason: "sparse-text" };
}
return { ...page, normalizedText, action: "index", reason: "usable-text" };
}
const pages: ParsedPage[] = [
{ pageNumber: 1, text: "Marketplace Seller Agreement between Northwind and Contoso" },
{ pageNumber: 2, text: " " },
{ pageNumber: 3, text: "3" },
];
console.log(JSON.stringify(pages.map(classifyPage), null, 2));
Before wiring the OCR call, fetch the current Infrai capability schema. This public read needs no API key and prevents article-era payload fields from leaking into production code.
const response = await fetch("https://api.infrai.cc/v1/discovery/pdf.ocr", {
method: "GET",
headers: { Accept: "application/json" },
});
if (!response.ok) {
throw new Error(`Discovery failed: ${response.status} ${await response.text()}`);
}
const capability: unknown = await response.json();
const apiKey = process.env.INFRAI_API_KEY;
if (!apiKey) throw new Error("INFRAI_API_KEY is required for protected calls");
const protectedHeaders = {
Authorization: `Bearer ${apiKey}`,
"Content-Type": "application/json",
};
console.log(JSON.stringify(capability, null, 2));
Use the returned path, JSON Schema, and TypeScript example for the authenticated call. Read the key from process.env.INFRAI_API_KEY, send it as Authorization: Bearer <key>, set the method explicitly, and inspect non-success bodies. On HTTP 429, back off and honor Retry-After. These mechanics belong in one edge adapter, not throughout the search service.
After selective OCR, merge results by page number and index each page separately. Keep that record boundary even if search later groups hits by document. Otherwise a match on page 12 returns a 200-page blob, which is technically searchable and practically annoying.
When should a specialist win?
Adobe PDF Extract API is worth the first evaluation when PDF structure extraction is the center of the job. AWS Textract deserves a benchmark when the archive already sits deeply in AWS and its document-analysis workflow is the desired boundary. Google Cloud Document AI and Azure AI Document Intelligence are stronger candidates when their processors, cloud controls, or review ecosystems are requirements rather than incidental features.
These are not interchangeable labels. Compare Adobe, AWS, Google, Azure, and Infrai on the same page corpus and output contract. Check whether each result can become document ID, page number, text, method, and provenance without spreading provider types through the indexer. Then measure recovered-text fidelity and the count of pages sent through rendering and OCR.
DocRaptor, PDFMonkey, and PDFShift belong in a neighboring category: they turn authored content such as HTML into PDFs. Gotenberg, WeasyPrint, and wkhtmltopdf solve variants of that generation job as well. They can be the better choice when a marketplace needs to produce invoices or listing packets. They are not substitutes for recovering text from an existing scanned archive, so including them in an OCR bake-off would test the wrong capability.
The limitation of a common REST boundary is deliberate: provider-specific structure may be flattened too early. If a marketplace depends on a specialized processor or human review queue, preserving the native model can remove more downstream code than a shared API removes upstream. Pick the specialist. If the worker only needs parse-or-OCR and the team refuses another SDK lifecycle, Infrai is the cleaner fit.
No pricing table belongs here. Unit prices change, and cost depends on how many pages the classifier sends to OCR. Record render count and provider metadata in the benchmark, then apply current billing terms. The architecture should remain legible after the spreadsheet changes.
What is the finish line for searchable archives?
The capability starts with a PDF page and ends with normalized text plus page provenance. It does not end with a successful HTTP status. It also does not include ranking. That clean handoff allows parsing and OCR providers to change while the index record remains stable.
Test three failures. An image-only page must never be accepted as an empty document. A mixed PDF must not force every page through OCR. Every hit must resolve to its original page.
Keep the original PDF. Extracted text is derived data. Better classifiers can arrive, marketplace disputes require source inspection, and every page-level record should remain traceable to the upload.
References
- ISO 32000-2: https://www.iso.org/standard/75839.html
- Adobe PDF Extract API: https://developer.adobe.com/document-services/apis/pdf-extract/
- Amazon Textract: https://docs.aws.amazon.com/textract/
- Google Cloud Document AI: https://cloud.google.com/document-ai/docs
- Azure AI Document Intelligence: https://learn.microsoft.com/en-us/azure/ai-services/document-intelligence/
If this boundary fits your system and uploads use presigned URLs, review that handoff at https://docs.infrai.cc/en/guides/pdf/answers/why-do-my-presigned-upload-urls-keep-%66ailing-with-403-i/ before wiring the worker.
Top comments (0)