Pricing

from $4.00 / 1,000 ocr pages

Try for free

Go to Apify Store

OCR Text Extractor - Image & Scanned PDF to Text

Try for free

English OCR for PNG, JPEG, PDF. Pages are OCR'd as images; PDF text layers aren't copied. From $4/1,000 pages with text + start fee $0.005/GB RAM per run.

Pricing

from $4.00 / 1,000 ocr pages

Rating

0.0

(0)

Developer

Luxe Tasks

Actor stats

Bookmarked

Total users

Monthly active users

20 hours ago

Last modified

Changelog

0.1.0 candidate 4.4.3 (Oct 26, 2026)

Built-in sample page: a run with no files (files missing, null or empty, or no input at all) now reads only a bundled synthetic one-page PDF (assets/sample-page.pdf, made by scripts/make-sample-page.mjs; its sha256 is checked at run time) and writes one dataset record marked sample: true. Sample pages are never charged (no ocr-page event); Apify's start fee still applies. Before, such a run failed with "files must be a list". No attestation is needed for the sample; the other input fields are still validated.
A run with any files works exactly as before and never includes the sample. File URLs still need documentRightsAttestation (default false), and the SSRF, robots.txt, URL-cap and run limits are unchanged.
Input schema: files is no longer required (so an empty run from the Store reads the sample); its description says so.
README: the Input, Pricing and Output sections mention the sample. The dataset's Results view shows the sample column.
A restarted sample run that had already finished writes no second sample record.
Start-up log line (wording only): when the requested concurrency is reduced, the line now prints the true number of files that fit the formula. At 1024 MB and the default concurrency 3 it said "976 MB fits 1 file(s) at once" although 0 fit; it now says "976 MB fits 0 file(s) at once (...; minimum 1)". Effective concurrency and memory limits are unchanged (still 1 file, 679 MB).
Sample run messages: the final status message now reads "Sample page read (success); sample pages are not charged (Apify's start fee still applies)." If the bundled sample file is missing or damaged, a run with no files now fails with a one-line status message instead of an error trace (no dataset items, no pages charged). Runs with files are not affected.
Output schema added (.actor/output_schema.json): links to the dataset's Results view, the key-value store's text records and RUN_SUMMARY.
Source comments and this changelog no longer cite internal review item numbers. No behaviour change.

0.1.0 candidate 4.4.2 (Oct 26, 2026)

Wording only, in this changelog: the 0.1.0 limits note now says which pages are charged when a limit stops a file (pages stopped by a limit are not charged; pages already read before a run limit stopped the file are; a render_memory_limit file is not charged at all), and the 4.4 note says the start-up line's memory source label changed on Apify (numbers unchanged). No code change.

0.1.0 candidate 4.4.1 (Oct 25, 2026)

Wording only: a source comment in the memory module and the 4.4 notes below. No code change (same behaviour as 4.4).

0.1.0 candidate 4.4 (Oct 25, 2026)

Memory units corrected: the platform's memory setting is decimal MB (a 1024 MB run has a container limit of 1,024,000,000 bytes = 976 MiB). The cgroup reading (bytes / 1,048,576) was already right; the memory environment variables are now converted the same way (1024 -> 976 MiB) instead of being used as MiB, so a run without a readable cgroup limit plans the same budget as one with it. No numeric change on Apify, where the cgroup limit is read (same concurrency and limits as 4.3; only the start-up line's memory source label changes, see below). The 4.3 note below had the units backwards.
The start-up log line says "fits 0, minimum 1" when not even one file fits the formula (1024 MB runs).
Start-up log line on Apify: it now says "memory from ACTOR_MEMORY_MBYTES" (4.3 said "memory from cgroup /sys/fs/cgroup/memory.max (below ACTOR_MEMORY_MBYTES=1024)"). The converted setting (976 MiB at 1024 MB) now equals the container limit, so it is no longer overridden by it; the memory, concurrency and limits in the line are the same as in 4.3.
Fix for runs where the container limit cannot be read (memory taken from ACTOR_MEMORY_MBYTES / APIFY_MEMORY_MBYTES only): Apify's MB are 10^6 bytes, but 4.3 used the number as MiB (2^20 bytes), so a 1024 MB run was planned as 1,073,741,824 bytes against a real limit of 1,024,000,000: about 5% too much, roughly the whole 5% headroom. 4.4 plans 976 MiB (49 MiB headroom, renderer limit 679 MiB), the same as when the limit is read.

0.1.0 candidate 4.3 (Oct 25, 2026)

Decompression-bomb check before rendering now measures LZW and RunLength streams (before, they counted at their stored size), and Brotli; filters it cannot measure are refused (file_bomb, not charged): unknown filter names, and image formats (JPEG, JPEG 2000, CCITT, JBIG2) anywhere but as the last filter of an image. The filter is read the way the PDF renderer reads it (/F before /Filter, LZW EarlyChange).
Object streams are decoded with the same limits: one that expands to more than 32 MB, or all of them together to more than 64 MB, is refused (file_bomb); before, such an object stream was skipped and the pages inside it were not checked.
The container memory limit is read in MiB (bytes / 1,048,576); before it was divided by 1,000,000. (Corrected in 4.4: the platform's setting is decimal MB, not MiB; a 1024 MB run's limit of 1,024,000,000 bytes was read as 1024 MB before and 976 MiB now.)

0.1.0 candidate 4 (Oct 25, 2026)

Store description: "English OCR for PNG, JPEG, PDF. Pages are OCR'd as images; PDF text layers aren't copied. Charged per page with text; $0.005/run start fee +$0.005/extra GB."
Memory: the number of files processed at once is reduced so that the worst case (every file rendering a PDF page and running OCR at the same time) fits in the run's memory with headroom: 1 file at 1 GB, 2 at 2 GB, 4 at 4 GB (was 5). Memory is read from the platform's memory setting or the container limit. The start-up log shows the requested and the effective number.
PDF renderers and OCR processes of a run now share one memory budget. If together they pass it, the largest renderer is stopped and that file ends as render_memory_limit (not charged). Each renderer is still limited to 700 MB.
Decompression-bomb check before rendering, extended: filters given indirectly, as arrays or as chains (Flate, ASCIIHex, ASCII85), page objects stored inside object streams and escaped filter names are understood; a page is refused (file_bomb, not charged) when its content streams and forms together expand to more than 160 MB, as well as when a single stream does. The renderer memory limit stays as the backstop for anything the check does not cover.
Fixed a rare extra page result when the renderer process was slow to shut down, or exited, after the last page.
File URL mode: a robots.txt that returns 429 is retried once only if Retry-After is 60 s or less; otherwise (or on a second 429) the domain is stopped: the first file is rate_limited, the rest skipped_blocked, no file is requested and nothing is charged. Before, a robots.txt 429 counted as "no restrictions", like other 4xx. README states the robots.txt status rules.

0.1.0 candidate 3 (Oct 25, 2026)

Pricing text: $4 per 1,000 pages with readable text (event ocr-page) plus a $0.005 start fee per run (Apify's apify-actor-start event, charged once up to 1 GB of memory and once per extra GB). The Store description now discloses the start fee.
PDF renderer memory limit: the renderer process is stopped when it uses more than 700 MB of memory; the file ends as render_memory_limit and is not charged, including pages already read. PDFs with a compressed stream that expands to more than 160 MB are refused before rendering (file_bomb). Both stop small "decompression bomb" files that could exhaust memory.
Uncharged work is now counted per page: blank or unreadable pages inside files that also have readable pages count toward the run limit, which is now 25 files, 500 pages or 10 minutes of work without readable text. A file in progress stops at its next page when the limit is reached (remaining pages uncharged_work_limit). With several files in progress, at most one extra page per other file.
Source package: tests, test fixtures, benchmarks, internal docs and local scripts are no longer included in the source archive, apify push upload or Docker build context.

0.1.0 (unreleased)

First version: local Tesseract OCR for PNG, JPEG and PDF (English).
Every page, including PDFs with selectable text, is rendered and read with OCR. Reading a PDF's embedded text layer first ("text-layer-first") is not implemented. If it ships, this README and this changelog will be updated together.
Limits on PDF rendering (per-page render time, per-file time, drawing operations per page, renderer memory) and per run (run time, uncharged work). Pages stopped by a limit are never charged; readable pages already read before a run limit stopped the file are kept and charged (a file stopped by render_memory_limit is not charged at all).
Kit synced to actor-kit 0.5.1-final5 (tag kit-v0.5.1-final5): uncertain charges count against the max-charge budget; a restarted run marks a possibly-charged file charge_uncertain instead of re-charging it; a redirected robots.txt is applied to the original host and an undetermined robots answer counts as disallowed; with pay-per-event pricing, a run whose pricing lacks the ocr-page event stops before any work, with nothing charged.
English model: the Docker image uses Alpine's tesseract-ocr-data-eng 5.5.2-r0 (tessdata 4.1.0, /usr/share/tessdata) instead of a bundled tessdata_fast file. Local accuracy on the synthetic corpus was the same (mean CER 0.0483 vs 0.0484, 12 pages charged in both).
Dockerfile: Tesseract and its model are pinned to 5.5.2-r0 and checked at build time; app files are owned by the runtime user. .dockerignore added (local test output, node_modules and .git are not copied into the image). The Docker build is untested locally.
URLs in per-file error messages have their query strings redacted, like everywhere else.
Files refused before processing (download failed, unsupported type, too large, URL caps) no longer count toward the uncharged-work limit.
The PDF renderer's start-up no longer counts against the per-page render timeout (it has its own 20 s budget, still within the file limit).
README: advice on choosing uploads vs file URL mode.

Facebook Comments Scraper

apify/facebook-comments-scraper

Extract data from hundreds of Facebook comments from one or multiple Facebook posts. Get comment text, timestamp, likes count and basic commenter info. Download the data in JSON, CSV, Excel and use it in apps, spreadsheets, and reports.

Apify

60K

4.7

(88)

Youtube Scraper (Pay Per Result)

apidojo/youtube-scraper

Experience unparalleled efficiency and depth with its ultra-fast capabilities in searching, URL, playlist, channel, and profile scraping. It comes equipped with a variety of filters to customize your data collection precisely. Plus, it's incredibly affordable at only $0.50 per 1000 videos!

API Dojo

47K

3.3

(21)

Tweet Scraper V2 - X Scraper / Twitter Scraper / X.com Scraper

apidojo/tweet-scraper

Lightning-fast search, URL, list, and profile scraping, with customizable filters. At $0.40 per 1000 tweets, and 30-80 tweets per second, it is ideal for researchers, entrepreneurs, and businesses! Get comprehensive insights from Twitter (X) now!

API Dojo

124K

3.9

(196)

YouTube Scraper

streamers/youtube-scraper

YouTube crawler and video scraper. Alternative YouTube API with no limits or quotas. Extract and download channel name, likes, number of views, and number of subscribers.

Streamers

192K

4.8

(196)

Facebook Search Posts

scrapeforge/facebook-search-posts

Search Facebook posts, pages, groups, people, videos and events by keyword. Returns detailed data including reactions breakdown, media URLs, and engagement metrics.

ScrapeForge

80K

3.7

(11)

Twitter (X.com) Scraper Unlimited: No Limits

apidojo/twitter-scraper-lite

Introducing Twitter Scraper Unlimited, the most comprehensive Twitter data extraction solution available. Our enterprise-grade scraper offers unmatched capabilities with a transparent event-based pricing model, making it perfect for both small-scale and large-scale data extraction needs.

API Dojo

54K

4.8

(100)

Facebook Search Scraper — People, Pages, Posts & More

memo23/facebook-search-scraper

The most complete Facebook search: people, pages, places, events, posts, videos and top — in one actor, no login and no cookies. Get names, URLs, profile pictures, verified badges, event dates, and post text with authors. Auto-paginates across results. Export to JSON, CSV or Excel.

Muhamed Didovic

19K

5.0

(2)

Facebook Search Scraper

danek/facebook-search-ppr

Scrap Facebook search results fast and easy. It is designed to be fast and efficient, so it can extract a large number of results for low price. It is also less likely to be blocked by Facebook.

Jan Danecki

65K

4.1

(18)

TikTok Scraper

clockworks/tiktok-scraper

Extract data from TikTok videos, hashtags, and users. Use URLs or search queries to scrape TikTok profiles, hashtags, posts, URLs, shares, followers, hearts, names, video, and music-related data. Export scraped data, run the scraper via API, schedule and monitor runs or integrate with other tools.

Clockworks

371K

4.7

(370)

TikTok Search Scraper: Keywords, Hashtags, Creators

xmolodtsov/tiktok-search-scraper

Scrape TikTok search results by keyword or hashtag and discover creators. Pay only per result. Views, likes, comments, shares, bookmarks, channel stats, music, subtitles and direct video URLs as JSON. Output compatible with popular TikTok scrapers. No proxies or login needed. Works via API and MCP.