Flag PDF pages that need OCR
Mark four pages as text, image, text, image and you learn that pages 2 and 4 need OCR while 1 and 3 are already searchable, with a short summary. Send only those pages to recognition and leave the rest alone. Free in your browser.
- Free
- Runs in your browser
- No sign-up
- Your data stays on your device
Run — free
Runs in your browser. Free, unlimited — your data never leaves this page.
Many PDFs mix born-digital pages that already carry a selectable text layer with scanned image pages that look fine on screen but yield nothing to copy, search, or index. Before you spend budget on full-document OCR or ship a file into a pipeline that assumes extractable text, you need a precise list of which page numbers actually lack a text layer. Empty input is rejected so callers never mistake silence for success.
Pages that look like text but are only pictures
Many PDFs mix pages created digitally, which already carry a selectable text layer, with scanned pages that look fine on screen but give nothing back when you try to copy, search or index them. Under the visible letters there is only an image. Tools that pull text out of the file receive empty results, full-text search skips the page, screen readers announce nothing useful and archives that expect real text fail without warning. Text recognition, or OCR, fixes that, but only on the pages that actually need it.
From a page-by-page check to a short work list
You tell the tool, page by page and in document order, whether each page has text that can be extracted; usually a quick check has already measured this. It does not open the PDF itself. It returns the pages that need OCR and the ones already searchable, both counted from page one, plus the totals, the share of pages that need work and a one-line summary. With four pages where the second and fourth are images, you get pages 2 and 4 to recognize and a ratio of 0.5. A common mistake is running OCR on every page of a large mixed document, which wastes time and money when half of it is already searchable.
What text-layer flags mean and why page-level OCR matters
A PDF page may render glyphs that look like text while still storing only a raster image underneath. Downstream tools that call extract-text APIs then receive empty strings, full-text search skips the page, accessibility readers announce nothing useful, and archival pipelines that expect native text fail silently. The practical remedy is OCR, but running OCR on every page of a large mixed document wastes time and money when half the pages already have a text layer.
The contract here is deliberately narrow: you already know—or a lightweight probe has already measured—whether each page has extractable text. Flags are interpreted in document order starting at page one.
What you can do with it
Selective OCR worklists
Turn a per-page text-layer probe into a one-based list of pages that still need OCR so batch jobs skip already-searchable pages.
Accessibility remediation tickets
Open page-level tickets for image-only pages that lack extractable text instead of flagging the entire document.
FAQ
Are page numbers zero-based or one-based?
One-based, matching how people and most PDF UIs number pages. The first flag is page 1, the second is page 2, and so on.
What does the OCR ratio tell me?
It is the share of the document that still needs recognition: pages without text divided by all pages. With four pages and two of them lacking text, the ratio is 0.5, so half the document needs work.
Why can a page that shows text still need OCR?
Because what you see may be a picture of text. Scanned pages often look fine on screen while storing only an image, so copying, searching and screen readers get nothing from them.
Why not just run OCR on the whole document?
In a mixed file, many pages may already have a text layer. Recognizing only the flagged pages saves time and money and avoids processing pages that can already be searched.
What happens if the value for one page is invalid?
The check stops and names that page, counted from one, so you can fix the step that produced the list. An empty list is refused too, so silence is never mistaken for success.
Related tools
For developers — API access
Everything on this page is available programmatically. This section is for teams who want to wire it into their own systems; everyone else can just use the tool above.
API endpoint
Prefer to automate it? One authenticated POST creates the task; the result comes back by webhook or a signed link. The same capability also runs here on the web, by email and from Telegram — and soon from our app too.
Call it from your stack
curl -X POST https://api.kit.forhosting.com/pdf/searchable-ocr-flag \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"text_layer":[true,false,true,false]}'const res = await fetch("https://api.kit.forhosting.com/pdf/searchable-ocr-flag", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"text_layer": [
true,
false,
true,
false
]
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/pdf/searchable-ocr-flag",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"text_layer": [
true,
false,
true,
false
]
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/pdf/searchable-ocr-flag", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"text_layer":[true,false,true,false]}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"text_layer":[true,false,true,false]}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/pdf/searchable-ocr-flag", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Example request
{
"text_layer": [
true,
false,
true,
false
]
}Example response
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "pdf.searchable_ocr_flag",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}The API is asynchronous: the call returns a task_id immediately and the result arrives by webhook. Polling is capped at 1 req/s per task.
Pricing
Published price — no tokens, no invented credits. A failed task is never charged.
Limits
max_mb | 25 |
max_pages | 200 |
Errors
| HTTP | Code | Meaning |
|---|---|---|
401 | unauthorized | Missing or invalid API key. |
402 | insufficient_balance | Your balance doesn't cover the task price. |
404 | unknown_type | That task type doesn't exist. |
429 | rate_limited | Too many requests. Use the webhook instead of polling. |
Technical notes
This capability accepts that boolean presence map—true when a page has extractable text, false when it is image-only—and returns the pages that need OCR, the pages that are already searchable, counts, an OCR ratio, and a one-line summary.
What text-layer flags mean and why page-level OCR matters
You pass that ordered list of boolean flags; this endpoint does not open the PDF itself. true means the page is searchable and does not need OCR; false means the page is image-only (or otherwise lacks a text layer) and should be queued for OCR. The response lists needs_ocr_pages and searchable_pages as one-based page numbers, plus needs_ocr_count, searchable_count, all_need_ocr, all_searchable, ocr_ratio as needs_ocr_count divided by page_count, a pages array with per-page has_text_layer and needs_ocr booleans, and a human summary string suitable for logs and UI banners. That shape lets a batch job OCR only the flagged pages, skip already-searchable ones, and report coverage without re-parsing the PDF bytes a second time.
Input contract, response shape, and empty-list errors
Invalid tokens on a specific page fail naming the one-based page index so you can fix the probe that produced the map. POST a JSON body with text_layer, a required non-empty array of per-page presence flags in document order. Aliases pages, flags, and has_text are accepted for the same array. Each entry should be a boolean; the solver also accepts the numeric tokens zero and one and the common string tokens true, false, yes, no, y, n, zero, and one so CSV-style or form exports can be pasted without a pre-conversion step. An empty array, a blank string, a missing field, or a null value fails with invalid_input and a message that names text_layer and states that at least one page flag is required—those failures are not billed. On success the body echoes page_count equal to the flag length, needs_ocr_pages for every false flag, searchable_pages for every true flag, the two counts, all_need_ocr when every page needs OCR, all_searchable when none do, ocr_ratio rounded to twelve decimal places for stable tests across runtimes, the detailed pages array, and summary. Example: flags true, false, true, false yield page_count four, needs_ocr_pages two and four, searchable_pages one and three, needs_ocr_count two, ocr_ratio zero point five, and a summary that states two of four pages need OCR.
Where a needs-OCR page flag API earns its keep
Digitization desks receive mixed binders: native digital exports interleaved with flatbed scans. Accessibility remediation teams need a deterministic list of pages that fail selectable-text checks so remediation tickets can be opened page-by-page rather than document-wide. A preflight step that already measured text-layer presence can call this endpoint to produce a worklist of page numbers for the OCR queue without reopening multi-hundred-page files. Search and e-discovery platforms use the same flags to decide whether a document is index-ready or must wait for OCR, and the ocr_ratio field feeds quality dashboards that track how much of each intake batch is still image-only. Keep requests small, pin the ordered page lists in tests, and you get a reproducible gate between PDF inventory and OCR spend without standing up a document AI stack for a boolean scan.
Integration use cases
Intake and index readiness
Decide whether a mixed PDF is ready for full-text search or must wait for OCR using needs_ocr_count and ocr_ratio in your pipeline.
Technical questions
How do I flag PDF pages that need OCR?
Send text_layer as a non-empty array of booleans in page order (true = has extractable text, false = needs OCR). The API returns needs_ocr_pages, searchable_pages, counts, ocr_ratio, and a summary.
What happens if text_layer is empty?
The task fails with invalid_input. An empty or missing flag list is rejected so callers never treat silence as “no pages need OCR.” Failed validation is not billed.
Does this capability open or OCR the PDF file?
No. It only analyzes the boolean text-layer flags you provide. Use a separate PDF probe to measure flags and a separate OCR product to process the pages listed in needs_ocr_pages.
What does flagging PDF pages that need OCR cost?
The browser tool is free. API requests use prepaid KIT balance at $0.002 per successful call; invalid input is not billed.