A scanned PDF may look like a normal document, but each page is often just an image. You can read it on screen, yet you cannot reliably search for a name, select a paragraph, or copy a reference number. Optical character recognition, or OCR, solves that problem by detecting text inside the image and converting it into machine-readable characters.
ShotEasy OCR & Editable PDF brings that workflow into the browser. It uses PaddleOCR.js to recognize an image or scanned PDF locally, shows the detected text for review, and exports a PDF with a searchable text layer. The selected document is not uploaded to an OCR server.
What is PaddleOCR?
PaddleOCR is an open-source OCR and document AI project maintained by PaddlePaddle. The main project covers much more than basic image-to-text conversion. Its ecosystem includes scene text recognition, document parsing, structured output, multilingual models, deployment tools, and integrations for document-based AI applications.
The repository describes three broad areas of work:
- Universal text recognition for documents and natural scenes
- Structure-aware document parsing for PDFs, tables, formulas, and layouts
- Deployment options for local devices, servers, accelerators, and application frameworks
Those capabilities make PaddleOCR useful for projects ranging from receipt scanning and document indexing to RAG data preparation and large-scale document processing. However, not every PaddleOCR model or pipeline is intended to run inside an ordinary web page.
For browser tools, the important part is PaddleOCR.js.
What is PaddleOCR.js?
PaddleOCR.js is the official browser inference SDK available as @paddleocr/paddleocr-js. It allows a web application to run the PP-OCR text detection and recognition pipeline on browser-compatible image inputs.
The SDK accepts sources such as a File, Blob, ImageBitmap, ImageData, canvas, or image element. A prediction returns OCR results containing:
- The recognized text for each detected line
- Polygon coordinates describing the text region
- A confidence score for the recognition result
- Image dimensions and runtime metrics
This combination is important. Plain text alone is useful for copying, but coordinates make an editable document interface possible. A browser tool can position each result over the original page, let the user compare text with the scan, and preserve the approximate location when building a searchable PDF.
How PP-OCRv5 works in the browser
The browser SDK can run a PP-OCRv5 detection and recognition pipeline. The process has two core stages.
First, text detection examines the image and finds areas that look like text lines. These regions may be horizontal, compact, or placed at different positions across a page. The detector returns coordinates rather than attempting to understand the words.
Second, text recognition processes the detected regions and predicts the characters in each line. PaddleOCR.js returns the recognized text together with its confidence score and original polygon.
In practical terms, the workflow looks like this:
- The browser decodes the selected image.
- A scanned PDF is rendered into page images with PDF.js.
- PaddleOCR.js detects text regions on the page.
- PP-OCRv5 recognizes each detected line.
- The page displays editable OCR results over the scan.
- Corrected text is added to the exported PDF as a searchable layer.
ShotEasy currently processes one selected image or PDF at a time. For a multipage PDF, the file remains a single document while its pages are rendered and recognized locally.
Local OCR does not mean zero downloads
Browser OCR is often described as “local,” but it helps to define that term accurately.
The selected document and recognized text can remain on the user’s device. They do not need to be posted to a remote OCR API. At the same time, the browser still needs the public model and runtime resources required to perform inference.
PaddleOCR.js manages OpenCV.js and ONNX Runtime internally. WebAssembly provides a portable way to run the inference workload in a modern browser. On first use, the browser downloads the OCR model and WASM runtime. These resources may then be cached, so later recognition sessions are usually faster.
This creates a useful privacy boundary:
- Public OCR model and runtime files are downloaded.
- The user’s image or PDF is processed in browser memory.
- Detected text and edits remain in the current browser session.
- No document upload is required for recognition or PDF generation.
The first OCR run may take longer because model initialization is much heavier than opening a normal image editor. Performance also depends on document resolution, page count, available memory, CPU speed, and browser capabilities.
Why OCR results still need editing
Even a strong OCR model can make mistakes. Small type, motion blur, compression artifacts, unusual fonts, low contrast, curved pages, handwriting, and complex backgrounds can all affect recognition.
That is why a reliable OCR workflow should include human review instead of immediately exporting raw model output. ShotEasy provides two ways to check the result:
- Page review places editable fields over detected text regions.
- Full text presents the recognized lines in a simpler text-focused view.
Confidence scores can help identify lines that deserve attention, but a high score is not a guarantee that every character is correct. Important values such as account numbers, dates, names, legal references, and invoice totals should always be checked against the original page.
How a scanned PDF becomes searchable
OCR does not need to visually rebuild the whole document. A common searchable PDF technique keeps the original scan as the visible page and adds a text layer aligned with the recognized regions.
This approach has two advantages. The page still looks like the source document, including stamps, signatures, spacing, and imagery. At the same time, a compatible PDF reader can index, search, and select the OCR text.
Before export, ShotEasy uses the corrected line text rather than blindly using the first OCR prediction. The resulting PDF is useful for:
- Searching scanned reports and archived documents
- Copying text from receipts, letters, or printed forms
- Finding names and reference numbers inside PDF scans
- Making research material easier to index
- Preparing documents for later accessibility or knowledge workflows
OCR text layers are not the same as perfectly reconstructing an editable Word document. They improve search and selection while preserving the page image. Complex tables, columns, handwriting, formulas, and layout semantics may require more specialized document parsing pipelines from the wider PaddleOCR ecosystem.
Tips for better browser OCR results
Start with the clearest source available. A direct scan usually works better than a tilted phone photo. Make sure characters are large enough to distinguish, avoid heavy JPEG artifacts, and crop away unrelated backgrounds when possible.
For photographed documents, use even lighting and keep the page parallel to the camera. Shadows near a book spine and bright reflections on glossy paper can hide character strokes. If the source is already a PDF, use the original file instead of taking screenshots of individual pages.
After recognition, review low-confidence lines and any text containing numbers or uncommon names. The few seconds spent checking the result are usually more valuable than running the same low-quality source through OCR repeatedly.
PaddleOCR.js versus server OCR
Browser OCR and server OCR solve different operational problems.
Browser OCR is a strong fit when privacy, immediacy, and a simple single-document workflow matter. It avoids upload queues and keeps the original file under the user’s control. It can also reduce server storage and OCR API costs for a public utility.
Server processing may be more appropriate for large batches, centralized archives, shared processing jobs, extremely large documents, or pipelines that require powerful GPUs and advanced structure extraction. The main PaddleOCR project supports a much broader deployment ecosystem for those cases.
ShotEasy deliberately focuses on the smaller local workflow: choose one document, recognize it in the browser, correct the text, and export a searchable PDF.
Try local OCR in your browser
Open ShotEasy OCR & Editable PDF, select an image or scanned PDF, and recognition starts automatically. Review the detected lines, correct any mistakes, then export the searchable PDF.
The first run needs time to download and initialize the model. After that, browser caching can make the workflow faster while your document continues to stay on your device.