DEV Community: Apryse

JavaScript Spreadsheet SDK: How to Embed Excel-Like XLSX Editing into Your React App

Hanna Miller — Wed, 23 Sep 2026 17:59:16 +0000

The best JavaScript SDK for editing Excel files in the browser depends on the complexity of your spreadsheet workflows and the other document formats your applications need to support. If users need to open, edit, and export native Excel files with formulas, multiple sheets, and formatting intact, a dedicated spreadsheet SDK is generally a better fit than a data grid designed primarily for displaying tabular data. For teams already handling PDF or Word documents in the same application, Apryse Spreadsheet Editor SDK is a strong fit, since it runs all three formats through one client-side engine using WebAssembly, keeping files in the browser instead of round-tripping to a server. When spreadsheet editing is the only document type in scope, some dedicated spreadsheet SDKs specialize in extensive formula libraries or high-speed data streaming, which can be worth the tradeoff. Lighter-weight libraries fit budget-constrained, low-complexity projects.

Introduction

Data sovereignty and user experience are everything. Forcing your users to leave your app to edit a spreadsheet is a risky move. Whether they are downloading a sensitive financial report to open it in Excel or jumping over to a shared Google Sheet, you’ve lost control of the workflow, and potentially the security of that data.

Embedding a professional spreadsheet editor, like the Apryse Spreadsheet Editor, directly into your web application keeps the data in-house and the user focused.

Why Embed an Editor?

Google Sheets and Excel Online are powerful, but they work only until they don't. A dedicated JavaScript SDK gives you the control they can't:

Custom Branding: You aren't stuck with third-party logos or UI breaking your app's immersion.

Offline Support: A dedicated SDK, like the Apryse Web SDK, allows for in-memory editing that doesn't die the moment the Wi-Fi drops.

Data Sovereignty: Crucial for banks or healthcare; files are processed in the browser, not on an external server.

Accessibility: Professional SDKs often come with WCAG 2.2-AA compliance out of the box.

Spreadsheet SDK vs. Data Grid: Knowing What You Need

You might think that a data grid, like AG Grid, can handle all your spreadsheet editing needs like a spreadsheet editor does, but in reality, they just can’t compete. They solve different problems:

Data Grids: Designed to render JSON data. They are great for sorting and filtering database records, but they don't handle .xlsx files very well, especially complex workbooks.

Spreadsheet SDKs: These are built for .xlsx files. They support cell merging, complex formula engines (SUMIF, VLOOKUP), and multiple tabs. If your users need to upload an Excel file, change a formula, and export it back out; you need an SDK.

Comparing the Top JavaScript Spreadsheet SDKs

The Benefit of a Unified Document SDK

Most enterprise apps manage a mixture of document types such as contracts (PDF), letters (Word), and reports (Excel). Using separate SDKs for each means multiple dependencies and inconsistent UI.

The Apryse Spreadsheet Editor (a WebViewer add-on) handles all three in one component. Since Summer 2025, it has supported full client-side editing, performing all operations in memory via WebAssembly. This ensures sensitive data, like financial proposals or compliance checklists, never leaves the client’s machine. It even supports chart rendering and editing, so users can refine data points and see visual updates in real-time.

Common Use Cases

Financial Proposals: Banks can present Excel-based proposals safely within their portals without sensitive data leaving the browser.

Compliance Checklists: Users can view and edit templates without file downloads or format breakage.

Collaborating on Reports: Generate spreadsheets for client reviews without users having to switch tools.

How to Embed Apryse Spreadsheet Editor into a React App

Embedding a spreadsheet editor into your React app is a straightforward process. The engine is entirely client-side, meaning you can load files from local storage or remote URLs.

For a quick reference of the whole set up, check out the React with Vite video for Spreadsheet Editor 11.10+. It shows the integration of the Apryse WebViewer with Spreadsheet Editor enabled, all within a React project.

Note: If you are using Vite 8, see our blog on how to handle an error when trying to access WebViewer.

Prerequisites

Before we start setting up Spreadsheet Editor, we need to do some groundwork for our project:

Install Node and npm to use as your run-time environment/package manager.
Create a folder for your project.
Open a text editor like Visual Studio Code.
Get your Apryse trial key.

Now that we’ve done that, we can start our project.

Scaffold a React Project with Vite

First, we need to create the project.

On the command line, switch to the folder where you want your new project to sit.

Run the following on the command line:

Shell
npx create-vite@latest

Next, complete the following tasks from the command line during project creation:

Change the default Project name to a project name of your choice.
Select React for your framework.
Select JavaScript for your variant.

Navigate to the New React Project

Enter the following on the command line to navigate into your new project, replacing with the name you chose:

Shell
cd <project-name>

Integrate WebViewer

Run the following command on the command line, from your React project directory:

Shell
npm install

Then run the project with this command:

Shell
npm run dev

Now we can start editing the code in the files using Visual Studio Code as our editor.

Copy Static Assets

Let’s install vite-plugin-static-copy so that when we install WebViewer, all the static assets that are required will be copied over.

Shell
npm i -D vite-plugin-static-copy

Let’s also edit the vite.config file to specify where to copy the files from and to. After adding the necessary code, the vite.config file should look like this:

JSX
import { defineConfig } from 'vite' 
import react from '@vitejs/plugin-react' 
import { viteStaticCopy } from 'vite-plugin-static-copy' 

// https://vite.dev/config/ 
export default defineConfig ({ 
  plugins: [react(), viteStaticCopy({ 
    targets: [ 
      { 
        src: 'node_modules/@pdftron/webviewer/public/*', 
        dest: 'lib/webviewer' 
      } 
    ] 
  }) 
], 
})

Install WebViewer

To install WebViewer, run the following command:

Shell
npm i @pdftron/webviewer

Now we’ll set up our CSS files. First, delete all the contents from the app.css and index.css files.

Note: Don't delete the files completely in case you want to add your own CSS later.

Next, let’s modify the app.css file to specify the height of the webviewer class. Your code for this file should now look like this:

CSS
.webviewer{
height: 100vh;
}

Setting Up the App

In the app.jsx file, delete most of the code so that your file looks like this:

JSX
import {  } from 'react' 
import './App.css' 
function App() { 
  return ( 
    <> 
    </> 
  ) 
} 
export default App

Now we’ll add some code back into the app.jsx file to import WebViewer and enable Spreadsheet Editor. The file should now look like this:

JSX
import { useRef, useEffect } from 'react' 
import WebViewer from '@pdftron/webviewer' 
import './App.css' 
function App() { 
  const viewer = useRef(null) 
  const isInstantiated = useRef(false) 
  useEffect(() => { 
    if (isInstantiated.current) return; 
      isInstantiated.current = true; 
      WebViewer({ 
         path: 'lib/webviewer', 
         licenseKey: 'YOUR_LICENSE_KEY ', 
         enableFilePicker: true, 
         initialMode:WebViewer.Modes.SPREADSHEET_EDITOR 
      }, viewer.current).then((instance) => {}) 
}, []) 
  return ( 
    <> 
        <div className="webviewer" ref={viewer}></div> 
    </> 
  ) 
} 
export default App

And now we have a React app with Spreadsheet Editor running and able to view and edit spreadsheets.

The most important line of all the code above is:

JSX
initialMode:WebViewer.Modes.SPREADSHEET_EDITOR

This single line of code transforms your app from a PDF editor into a spreadsheet editor, opening up a world of new functionality.

What Can We Do Now?

There’s a wide range of modifications you can now make to a spreadsheet including changes to sheets, rows and columns, individual or groups of cells, formulas, and more. Check out our Spreadsheet Editor - Edit Mode page for examples with code.

FAQ

What file types are supported?

The editor is purpose-built for high-fidelity .xlsx viewing and editing.

Does this work on mobile?

Currently, the Spreadsheet Editor add-on is not supported on mobile browsers due to the complexity of the grid interactions.

How does client-side editing improve security?

Because it uses WebAssembly (WASM), the file is never uploaded to a third-party server for processing.

Is search and replace available?

Yes. Developers can perform search and replace programmatically across the entire workbook.

Conclusion

As we’ve seen in this blog, adding spreadsheet editing capabilities to an app is easily done using the Apryse Web SDK and Spreadsheet Editor add-on.

Choosing a Spreadsheet Editor SDK is about maintaining the integrity of your users' data. By bringing these capabilities in-house, you reduce workflow interruptions and ensure your sensitive data stays exactly where it belongs: inside your application.

Check out our Spreadsheet Editor demo or get started with the Apryse Web SDK.

For support or sales questions, you can contact our sales team.

Additional Apryse Suggested Reads

How to Create a Browser-based Spreadsheet Editor Using TypeScript, React and Vite

Hanna Miller — Thu, 17 Sep 2026 18:23:42 +0000

To add spreadsheet editing to a React application, use a document SDK that renders Excel files natively in the browser. Apryse WebViewer provides this through its SpreadsheetEditor mode, installed via npm and mounted directly in a React component. Spreadsheet support requires WebViewer instantiated as an Iframe, not a WebComponent.

Setup takes four steps:

Install the package: Add WebViewer to your project via npm install.
Configure assets: Copy WebViewer's static assets with a Vite plugin.
Mount the component: Attach WebViewer to a div element using a useRef hook.
Set the mode: Pass initialMode: WebViewer.Modes.SPREADSHEET_EDITOR in the constructor options. You'll need a valid license key, available with your free trial.

While Google Sheets or an embedded Office editor fill the gap, those options move your data into a third-party environment. Keeping spreadsheets in the browser can reduce exposure of downloaded copies or hidden columns. A working implementation of Apryse Spreadsheet Editor SDK runs under 40 lines.

Summary: Learn how to securely view and edit spreadsheets directly in the browser using the Apryse Web SDK. This guide covers integration with a React + Vite app, offering a lightweight, secure alternative to traditional spreadsheet tools—no Office license or external services needed.

Introduction

Spreadsheets are more than just a tool for accountants—they're a flexible, lightweight data platform used across virtually every industry. From financial modeling in banking to inventory tracking in retail, from experiment logging in scientific research to project planning in construction, spreadsheets remain a critical part of day-to-day operations.

In the past, if you needed to view or edit a spreadsheet, you would download it, edit it in a desktop or browser-based app then save it again. While that works, it risks copies of the spreadsheet getting left on the hard drive, with associated risks of confidential data being compromised in a ransomware attack or data breach. Working with spreadsheets in a general editor also risks copies being inadvertently shared with confidential data in hidden columns.

You could, of course, use the Google offering, but there are significant security risks with Google Sheets too.

So, what’s an alternative?

Enter Apryse

The Apryse Web SDK has been around for several years – first offering the ability to view and edit PDFs using WebViewer, then since 2024, the ability to edit DOCX files entirely within the browser (without needing an Office license), and now, supporting, viewing and editing Spreadsheets.

Better still, it’s easy to get started. If you are already an Apryse Web SDK user, you only need to change one line of code to get the benefit of this functionality.

In this article we will step through what is needed to view and edit Spreadsheets in a React based application that runs within your browser, and we’ll do that using Vite.

Learn how to integrate Apryse WebViewer in JavaScript, React, Vue, Angular, and more in this video.

A few words on configuration

I’m using Windows 11, but everything that you see should also work with macOS and Linux.

You will need npm and Node installed. I used Node v 22 for this article.

Step 1. Scaffold the app using create-vite

In a terminal window create a new app using:

Shell
npx create-vite@latest

This will take you through a series of steps where it will ask you to specify a project name (I called it “spreadsheet-editor”), a Framework (choose React) and a variant (choose TypeScript).

After a moment or two the project will be scaffolded, and you will be advised how to get started.

Navigate to the directory and install the dependencies using npm install.

If you want, then you can run the project at this point - it currently is just the default Vite+React app, but it’s useful to know that everything is working.

Step 2. Remove the default code
Copied to clipboard
Vite scaffolds a fully working app, but much of what was created isn’t needed, so let’s delete that.

You could do this from the command line or another IDE, but I’ll open the project in VSCode.

First, remove everything from the App.css file. We will want to add things back in as we move from a prototype to production, but for now we can just delete all of the contents.

We will also remove the contents of the index.css file at this point.

Next remove virtually everything from the App.tsx file.

Step 3. Get ready to install WebViewer

Great, we have now got to the point where we can start rebuilding. We need to add Apryse WebViewer which we can do using npm install. Apryse was previously known as PDFTron and rebranded in 2023. As such, the WebViewer package still uses the name “pdftron” in its title.

WebViewer is written using JavaScript and is intended to be used within the browser. As such, we need to make sure that our code can access the files at runtime. For security reasons React can only access files in the project’s public folder, and not from the node_modules folder.

There are various ways that we can make those static files available at runtime – we can copy them manually, run a script, or use a plugin.

For this article we will install the plugin vite-plugin-static-copy.

Shell
npm i -D vite-plugin-static-copy

In addition to installing the plugin, you will also need to update the vite.config.ts file to specify where the files should be copied from and to.

TypeScript
import { defineConfig } from 'vite' 
import react from '@vitejs/plugin-react' 
import { viteStaticCopy } from 'vite-plugin-static-copy' 

// https://vite.dev/config/ 

export default defineConfig({ 
 plugins: [react(), 
  viteStaticCopy({ 
  targets: [ 
   { 
    src: 'node_modules/@pdftron/webviewer/public/*', 
    dest: 'lib/webviewer' 
   } 
  ] 
 }) 
 ], 
})

Now when we install Webviewer, the plugin will copy the files in 'node_modules/@pdftron/webviewer/public/’ into 'lib/webviewer'

You can specify an alternative destination if you wish – but if you do then you will need to modify the WebViewer initialization code – we will talk about that in a moment.

Step 4 - Install WebViewer

Next, we need to install WebViewer itself, which we can do using npm.

Shell
npm install @pdftron/webviewer

This will copy the package into node_modules and add it to the package.json file.

Note: If you have chosen not to use the plugin, then you will need to manually copy the files from the public folder into a location where they can be accessed by the client.

Step 5. Create an HTML element where WebViewer will be mounted

Now within the App.tsx file, add some html to create a div where WebViewer will be mounted. We will specify the element with a useRef and also include a className to allow us to style it with CSS.

Your entire App.tsx file should now look like:

JavaScript
import {useRef} from 'react' 
import './App.css' 

function App() { 
 const viewer = useRef(null) 
 return ( 
  <> 
   <div className='webviewer' ref={viewer}></div> 
  </> 
 ) 
} 
export default App

Step 6. Instantiate WebViewer

WebViewer can be instantiated as a WebComponent (the default option), or as an Iframe. When working with the SpreadsheetEditor, WebViewer must be instantiated as an Iframe.

The WebViewer constructor allows us to specify various options and requires us to include the element where it should be mounted (in our case viewerDiv.current).

In this example we will specify three important options:

path: which indicates the location where the plugin will be copying files to.
licenseKey: which includes the trial or commercial license. If you haven’t got one, then it is free to get a trial license for WebViewer.
initialMode: which specifies whether WebViewer should have the initial UI for working with PDFs, DOCX files or Spreadsheets. We will use WebViewer.Modes.SPREADSHEET_EDITOR.

There are many other options that you can use (check out the WebViewer documentation), but for now we will just use enableFilePicker, so that we can choose files from the UI, and initialDoc (in this case “invoice_template.xlsx“) to specify the file that should be loaded when WebViewer is created.

The WebViewer constructor is async and returns a promise. When the promise resolves, you can use the instance object to work with WebViewer. We won’t need that just now for our simple app, but we will create an empty code block so that it is available when you decide to further explore what WebViewer can do.

Our constructor should now look like:

*TypeScript
WebViewer.Iframe({ 
   path: "lib/webviewer", 
   initialMode: WebViewer.Modes.SPREADSHEET_EDITOR, 
  licenseKey:"[Your license key]", 
   enableFilePicker: true, 
   initialDoc:"invoice_template.xlsx" 
  }, 

   viewerDiv.current as HTMLDivElement).then())

As we are using React, we can put this code into a UseEffect hook with an empty dependency array so that it fires when the component mounts.

In recent versions of React the useEffect will fire a second time for Debug builds if strict mode is true.

There are several workarounds that I have used at different times. My preferred method at the moment is to create another useRef variable (“isInstantiated”) and only instantiate the WebViewer if that has not already occurred. This adds a little extra code that isn’t needed when you move to production but will be useful during development.

Your entire App.tsx file should now look like

JavaScript
import { useRef, useEffect } from 'react' 
import './App.css' 
import WebViewer from '@pdftron/webviewer' 

function App() { 
 const viewerDiv = useRef<HTMLDivElement>(null) 
 const isInitialized = useRef<boolean>(false) 
 useEffect(() => { 
  //Not needed in production 
  if (isInitialized.current) return 
  isInitialized.current = true 

  WebViewer.Iframe({ 
   path: "lib/webviewer", 
   initialMode: WebViewer.Modes.SPREADSHEET_EDITOR, 
   licenseKey:”[Your license key]”, 
   enableFilePicker: true, 
   initialDoc:"invoice_template.xlsx" 
  }, 

   viewerDiv.current as HTMLDivElement).then((instance => { 

   }) 
   ); 
 }, [ 
 ]) 

 return ( 
  <> 
   <div className='webviewer' ref={viewerDiv}> 
   </div> 
  </> 
 ) 
} 

export default App

At this point the code is effectively complete, so you can start the project using npm run dev.

You may find that the Spreadsheet editor appears to load but no grid is available.

If you look in the browser’s DevTools window, it shows messages to indicate that WebViewer has loaded, and we can even see the name of the file at the top of the browser too.

This isn’t a problem with WebViewer – it’s a CSS issue.

Step 7. Solving issues with CSS

When you have a real app, you will spend a lot of time carefully crafting the CSS for it, but straight out of the box this can be confusing. The fix is straightforward - add CSS to specify the height for the webviewer class (which we specified in the div where WebViewer is mounted).

CSS
.webviewer{
height: 100vh;
}

Now when you reload the page, you can see a fully functional WebViewer. Awesome work!

Where next?

With less than 40 lines of code, and as little as 10 minutes from creating the project, you now have a running project containing a Spreadsheet Editor within a web page.

Getting The Spreadsheet Editor running is just the beginning though. We’ll look at how we can work with the API in the next blog in this series, as a way to work programmatically with the contents of the Workbook.

The Web SDK offers more than just the ability to work with spreadsheets. With just a few changes to the code you can view and edit DOCX files, or PDFs. You can even set up a complete workflow for generating files from a template, converting them to a PDF, then digitally signing them.

One tool – a wealth of uses!

Don’t just take my word for it though – try it our for yourself. Get a trial license and see what you can do. If you have any questions, then reach out to us on our Discord channel and we will be happy to help.

Can you vibe code a DOCX editor for $200?

Julie Love — Thu, 10 Sep 2026 20:44:10 +0000

Quick Answer: A weekend with Claude will get you a browser-based editor that opens a .docx, renders the paragraphs, lets you type, and saves it back out. That part is real and it is genuinely impressive. What the $200 does not cover is the rest of the OOXML spec, the security work that comes with accepting files, the round-trip problem, and someone who understands the whole thing for the 2am fire drill. Generating code got cheap. Owning code did not.

I recently found this comment under a demo video for the Apryse DOCX editor:

"You can vibe code one better than that one with Claude so it will probably cost you 200 and you are better off doing that way since people are definitely gate keeping code that is technically free to make."

I think there are a lot of people excited about the possibilities of where we are with vibe coding. I hate to ruin a good buzz but can't resist bringing a bit of sobriety into this conversation. Sadly, the reality of owning code is never quite as fun as the imagination phase.

What does a weekend and $200 actually get you?

Quick Answer: Real code that runs. A .docx is a ZIP file full of XML, so pulling paragraph text out of document.xml is genuinely an afternoon's work, and what comes back opens real files and saves them again. But there is quite an expanse between "working" and great code. The distance between them is ECMA-376: several thousand pages, of which your weekend covered whatever your test file happened to use. Almost none of the rest is exotic.

Here is what is sitting past that quick vibe output, and none of it is unusual. This is just Tuesday for anyone who works on documents:

Numbering. Abstract definitions, concrete instances, per-level overrides, and restart semantics that nobody agrees on.
Styles. Inheritance running from document defaults, through linked and latent styles, down to direct formatting on a single run.
Section properties. Which can change halfway down the file, because of course they can.
Tables. Vertical merges expressed as continuation flags on the cells below rather than on the cell doing the merging.
Fields. Storing both a cached result and the recipe to recompute it, so you have to decide which one you believe.
Everything else. Footnotes, content controls, equations, bidirectional text, embedded objects.

None of that is hidden from you. It is just a whole lot more work than people are expecting to do when they "open a .docx".

The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time. - Tom Cargill, Bell Labs

Why does every "can it also do..." request cost more than it sounds?

Quick Answer: Because the cost of saying yes collapsed but the cost of the resulting system did not. Version 0.1 gets shown around, the requests come back, each one sounds like an afternoon, and each one lands somewhere much larger than the person asking realizes.

Where those small requests actually land:

"Can it do numbered lists?" Abstract versus concrete numbering, level overrides, restart rules, list styles.
"The indents look wrong." Indent resolution and tab stops. Congratulations, you are now maintaining a layout engine.
"Print it exactly like Word." Line breaking, font metric substitution, widow control, keep-with-next, rows splitting across pages.
"Keep the tracked changes." Insertion, deletion, move and format revisions, and every single edit your editor makes now has to be expressible as one of them.
"Where did the comments go?" See the round-trip section. This one is the mean one.

Six weeks later there are twenty thousand lines in the repo and you have read maybe three thousand of them. The three thousand that broke.

What if you don't control what is uploaded?

Quick Answer: The moment you accept uploads, you have an endpoint consuming arbitrary compressed XML sent by strangers. That is one of the more hostile input classes in computing.

A few of the vulnerability classes to consider:

XXE. Your XML parser will read files off your server unless somebody explicitly told it not to.
Decompression bombs. A few kilobytes of ZIP that expands to gigabytes.
Zip slip. Archive entries containing ../, writing wherever they like the second you extract to disk.

Every one of those appears in the CVE history of every mature document library, found the expensive way - by someone else, years ago.

What is the round-trip problem?

Quick Answer: The failure people brace for is a crash. The failure that actually happens is silent. If you parse a document into your own model and serialize it back out, it drops everything your model did not know about - with no error report in sight.

Someone opens a contract in your editor, changes one word, saves. The tracked changes are gone. So are the comments, the custom XML bindings a downstream system reads, the content controls, and the numbering that survived four rounds of legal review.

The file opens fine. Word does not complain. It simply is not the same document anymore, and nobody finds out until the moment it matters most.

Preserving the parts you do not understand is much harder than parsing the parts you do. No prompt is going to tell you which parts you did not understand, because by definition, you didn't ask.

Can you maintain code you have never read?

Quick Answer: Software cost lives in maintenance, and maintenance cost is a function of comprehension. Code generation drives the writing cost way lower but it does nothing for the comprehension cost. In fact it most likely makes comprehension worse, because writing the code is how you would otherwise have learned the code.

The question at the point of failure is never "can Claude fix this." It is "do I understand this system well enough to know whether that fix is right, or whether it just moved the bug somewhere I am not currently looking."

Writing scales with the model. Debugging still scales with you. Even after coding for many years, I still struggle to remember exactly what I meant in every line of code that I actually wrote - much less trying to decipher where the AI went wrong on something I had nothing to do with.

Is anyone actually gatekeeping this?

Quick Answer: No, and this is the part of the comment that holds up the least. Plenty of sources out there. LibreOffice is open. So are docx4j, python-docx and a dozen readable OOXML implementations. Nobody is hiding the code, because the code was never the scarce part.

Everyone deserves to be paid for their work. When you make the call to buy vs build, it's rarely because no one is capable of building it. You pay to keep your dev resources focused on solving your own business problems. You pay for that other company to be the expert for your team.

That expert brings years of experience with:

The zillions of real documents produced by 20 years of Word versions and every third-party generator that emits technically invalid XML which Word renders anyway.
The bug report from the customer whose merged table cells collapse only at 120% zoom.
Somebody to call when a filing renders wrong just before the deadline.
The unglamorous rest of it: security review, indemnity, accessibility conformance.

This is not about a goblin wildly guarding lines of code while sitting on a pile of your money. This is just the part you cannot prompt into existence because it is not code. It is lived, often traumatic, experiences that you are paying to skip entirely. ...and it's often worth every saved minute of your time and avoided suffering.

Toss this problem back over the fence? Yes please, and thank you.

So when should you build it yourself?

Quick Answer: Frequently. For a great many jobs, spending $200 and a weekend is exactly the right call. Not every tool needs to reach perfection or hold up under long term testing and maintenance stress.

Build it yourself when:

You control the whole workflow, use your documents, and you know exactly how the in and out points need to function.
Your company or workload is small, no need to over-engineer for something that doesn't need to scale.
"Wrong" costs a redo, not a lawsuit.
Nobody outside the building is uploading anything, or more specifically, you can entirely trust the users of the system.
You would be happy to delete the whole thing next quarter. Throw it up, try it out, and no one is upset when you scrap it for the next iteration.

Reach for something battle-tested when:

The inputs are other people's documents, arriving from anywhere, in any state.
The data is other people's data, with residency or compliance rules attached.
The deadline is other people's deadline, and the failure lands on them. ...or worse, lands on you.
You need enterprise level scaling. There is no point in starting over on trying to account for every edge case an enterprise-level roll out will turn up.

Where should you start?

Build the weekend version anyway. It is the fastest way to find out how much of the format your use case actually touches.
Round-trip a really complicated document early. Tracked changes, comments, content controls. Save it, reopen it in Word, and see what quietly vanished.
Read the code you shipped. All of it, or at least enough to know which parts you have not read.
Decide which 90% you are in for. The first 90% is a weekend now, which is legitimately worth being excited about. The second 90% is the whole rest of your job.

If you get to step 4 and only have interest in that first 90%, then that is when a document SDK earns its keep. You can try ours for 30 days at docs.apryse.com/guides/get-started.

If you're on step 4 and think, "I've got this," go forth and prompt away! Then come back and tell me what broke. I have no doubt the answers here will keep changing as things advance - I'm super interested to see where we are.

Disclosure: I work for a company that sells document SDKs, so weigh all of the above accordingly. The vulnerability classes and the round-trip problem are real either way. Go check them against whatever you build.

Self-hosted OCR without a cloud API: where Tesseract stops working

Julie Love — Wed, 09 Sep 2026 18:49:17 +0000

Cover image caption: Puppy with "free" sign and collar that reads "self-hosted OCR". Next to that a long receipt titled "Maintenance" with many cost items for dogs.

Quick Answer: Ask your favorite AI how to run OCR server-side without a cloud API and you will most likely hear about Tesseract. That is a reasonable answer for clean, straight, single-column English print. It stops being reasonable once you read the weak spots Tesseract's own documentation flags, and start counting developer time as the cost that it is. A production OCR SDK, like Apryse, earns its license fee in exactly those places.

I asked ChatGPT, Claude and Gemini that question in several forms. Every one said Tesseract, usually with PaddleOCR and EasyOCR as close seconds. Not one mentioned that Tesseract publishes a page called "Improving the quality of the output" which, if we are being honest, is a long list of what it just does not do well.

It's pretty easy to see why these top the lists. Because Tesseract is free, genuinely good, 30+ years old, and has more written about it than any other OCR engine on this lovely little planet. Models synthesize consensus, and people sure love to write and talk about things that are "free". But it's distinctly not the only answer, and you need to make sure it's actually the right answer to YOUR question.

Where does Tesseract stop working?

Quick Answer: Five places, all of them documented by the Tesseract project itself. Skewed pages, tables, uneven page backgrounds, tightly cropped or heavily bordered regions, and anything that is not a sentence of dictionary words. None of these throw an error, they just return bad data - and that is usually the worse outcome.

Straight from the Tesseract documentation:

Skew. "The quality of Tesseract's line segmentation reduces significantly if a page is too skewed." Deskew is YOUR problem to fix, not the engine's.
Tables. "It is known tesseract has a problem to recognize text/data from tables without custom segmentation/layout analysis." Their wording, and the suggested remedy is a GitHub thread.
Uneven backgrounds. Binarisation runs internally with Otsu, and the result "can be suboptimal, particularly if the page background is of uneven darkness." Which describes most scans older than a decade.
Borders and crops. Too little border causes problems. Too much on a small region returns an empty page. The fix is cropping to a 10 pixel margin, by hand, per document type.
Non-prose text. Tesseract is "optimized to recognize sentences of words," so for part numbers and receipts the advice is to disable the built-in dictionaries. Invoices are mostly not sentences.

Then you add the 14 page segmentation modes you have to specify with --psm, because Tesseract will not determine the layout for you. Tesseract is an excellent recognition engine wrapped in a pipeline you are expected to build yourself, out of Leptonica, OpenCV or ImageMagick. And things you build, you must maintain.

What does "free" OCR actually cost?

Quick Answer: The license does not cost money, but you pay in developer time. The pre-processing pipeline, the per-document-type tuning, the model curation and the retraining are all work somebody on your team does instead of working on your product. Free OCR moves the cost from pocketbook to time - and that's some of the most expensive currency you have.

One of our customers came to Apryse having already built a full, working Tesseract solution. It was running just fine. The problem was that it was costing them 2-3 developers to keep it running. 2-3 devs who were constantly having to try and learn new things about the OCR ecosystem and how to keep it working. 2-3 devs who were supposed to be improving the PDF software that was actually the company's business.

They did not switch because Tesseract could not read their documents. They switched so Apryse was their expert, and responsible for the OCR upkeep. It meant their team could get back to focusing on their expertise and the internal roadmap items.

Once you look for it, you can see where those developer-hours go.

The pre-processing pipeline. Deskew, despeckle, binarisation, border handling, alpha channel stripping.
Language bindings. Tesseract is a C++ program. Reaching it from Python, Java, .NET or Node.js means a third-party wrapper, and pytesseract works by shelling out to the command-line binary as a subprocess. Those wrappers are community-maintained on their own release cycles, so they are one more dependency sitting between you and your text.
Per-document-type tuning. Choosing among 14 page segmentation modes, toggling dictionaries off for invoices and part numbers, cropping to the right margin. Every new document type restarts this.
Model curation. Tesseract publishes three sets of model files. tessdata_best is the most accurate and the only one you can fine-tune from, and it is also the slowest. tessdata_fast is documented as the least accurate, and it is what ships with Linux distributions. Most people are running the least accurate models and were never told. Each language is a separate file you download and manage.
Retraining, when preprocessing runs out. The training guide is honest about the price: the shipped Latin models were built from roughly 400,000 text lines across about 4,500 fonts, a training run takes "a few days to a couple of weeks," and it officially "only works on Linux." Retraining from scratch is called "a daunting task," with the warning that you will likely end up with a model that does well on your training data and badly on your real data.
Support. There is no one to call. Tesseract's own training guide asks you not to file training problems as GitHub issues and directs you to a mailing list instead.

To their credit, the project tells you not to retrain: "unless you're using a very unusual font or a new language, retraining Tesseract is unlikely to help." Honest advice, and it also leaves you nowhere to go on the day preprocessing has not closed the gap and the invoices still have to be processed.

For comparison, the Apryse v12 default engine covers 80+ languages including CJK from one model set. No files to curate, no accuracy tier to pick, no training step, and a support contract when it misbehaves. (Not to mention tools like Smart Data Extraction that help you do more with your OCR.)

None of this makes Tesseract a bad choice. It makes it a choice with a staffing plan attached. Price both.

What does a production OCR SDK give you that Tesseract does not?

Quick Answer: Pre-processing built into the engine rather than bolted on in front of it, several recognition engines behind one SDK so you can switch per document type, structured output with coordinates, and a support contract. You are paying for the pipeline around the recognition, not the recognition alone.

With the Apryse Server SDK, deskew and despeckle happen inside the engine. Since v12 the default engine runs on deep learning neural networks, bringing roughly 16% better word recognition, 80+ languages including CJK, and no GPU requirement. There are other engines available when your pages are unusual, which my OCR article covered in detail, and swapping between them is a one-line change rather than a new integration.

The bindings are native rather than wrappers. The same call runs from C++, .NET, Java, Python, Node.js, Go, PHP and Ruby, on Windows, Linux and macOS:

opts = OCROptions()
opts.SetEngine("default")      # "default", "alternative" or "iris"
opts.AddLang("eng")

# Inspect the result as JSON before it becomes a searchable PDF
json = OCRModule.GetOCRJsonFromPDF(doc, opts)
OCRModule.ApplyOCRJsonToPDF(doc, json)

That JSON is worth pausing on. You get recognized text plus coordinates, which means you can filter low-confidence words, reject a page, or map any answer back to the exact spot it came from, before any of it reaches your database or your LLM.

With Apryse you also get a multitude of tools that are ready to handle most any document need - AND you have Support. When something isn't going right, there's real help and a team to back you up.

Does self-hosting OCR solve compliance?

Quick Answer: While it does remove a whole category of problems, that's not the same as solving compliance for you. Running recognition in your own environment means no third-party processor in scope, no data residency question and no per-page metering. The rest of your obligations under HIPAA or GDPR are still architecture you have to build.

You may still have ninety-nine problems, but data residency ain't one.

Worth being precise, because vendors are routinely vague about it. An SDK is not "HIPAA certified." HIPAA compliance, as I'm sure you're aware if this is your area, is a property of your whole system. What self-hosting changes is that documents never leave your environment, so there is no processor agreement to negotiate, no cross-border transfer to justify and no third party whose breach becomes your incident.

The safety department of a large city came to us having done real homework, testing a range of options against two hard requirements: no training with their data, and nothing leaves their systems. The AI-powered engine in v12 met both and gave them the best accuracy of everything they tested.

And while we're on security - for those who get to be part of those ever fun security audits, nice to know that Apryse holds ISO/IEC 27001:2022 certification since 2018 and completes annual SOC 2 Type II audits. Usually keeps those security form pain points to a minimum.

Where should you start?

Quick Answer: Fix your input, then benchmark Tesseract honestly against your own worst documents before you spend anything. If it clears your bar and you have the headcount to maintain it, you've got your answer. If it fails in the ways its own documentation predicts or your budget does not account for maintenance efforts, you have a business case rather than a preference.

Check your DPI before anything else. Below 300 and you are debugging the scanner, not the engine. On a rasterized PDF, divide image pixels by page size in inches.
Build a test set of your worst fifty pages. Rotated, stained, multi-column, tabular. Good scans don't prove out your real cases.
Run Tesseract first, with real effort. Deskew, strip the alpha channel, pick the right --psm. Make sure it's a solid test to compare against.
Measure Character Error Rate and Word Error Rate per document type. Accuracy and how you manage it matters.
Price the developers, not just the license. Make some real estimates on what it is going to take to keep up with this longterm. When you are your only support team, it makes a difference.
Test the Apryse engines on the same set. Every module is in the 30-day trial with no page cap.

Tesseract is not the wrong answer. It is a good answer to "what is the best free OCR engine." But what if what you really need to know is "what will do the best job on my docs with the least longterm cost to my dev team"?

Models will only answer a question explicitly asked. Make sure you're asking the question you need answered.

Happy Coding!

Julie Love is Director of Developer Experience at Apryse. She has spent an entire career in tech spanning everything from burning CD screen savers to mastering proprietary code, sales engineering and a variety of in between. Puns always intended.

ICR handwriting recognition in Python: when do you need self-hosted instead of a vision LLM?

Julie Love — Wed, 09 Sep 2026 18:41:44 +0000

Quick Answer: Self-hosted ICR is a recognition engine trained on handwriting that runs inside your own network and can be set to return text plus coordinates. A vision LLM reads handwriting using an enormous training set and usually returns a block of text from someone else's server. Pay close attention to your needs around deployment, cost and audit-ability to make the best choices for you.

I've heard learning cursive in school is a thing of the past, much like my spiral notebook and my handwritten to-do lists.

Yes, there are usually doodles in my notebooks as well. It is great for those of us with visual and spatial memories who need to put ideas together on paper before they make sense anywhere else. (At least that is my justification and I am sticking to it.)

Luckily, kids these days do not need to learn cursive while we have so many cool digital toys now.

Let's break it down. (Due to the limitations of the written word, you will need to mentally cue a great late-80s hip hop track and a dance of your choice.)

Why is handwriting so much harder to read than printed text?

Quick Answer: Printed text follows solid, definable, repeatable rules. Handwriting breaks five of them at once, which is why handwriting support is not just a quick add-on to a printed-text engine. It has to be a separate model trained on separate data.

Everyone writes differently. This may be one of the world's largest understatements. Fonts are finite. Handwriting variation is not. (in the uncountable infinity category, for my fellow math nerds.) Even the same person writes the same letter differently depending on the number of lattes consumed and how annoying the traffic was on their way to fill out the form.
Cursive has no gaps. No need to mind the gap here, because there are none. No reliable boundary between characters means nowhere obvious to cut.
Words wander. Print sits on the line. Handwriting drifts, slants, and takes a little trip to any nearby region that looks fun or available.
Training data is scarce. Labeled handwriting collections are far smaller and rarer than printed text. Side quest, handwriting sample set: IAM Handwriting Database
Every source looks different. A doctor's note has nothing in common with an 18th-century census record. And let's be real, you thought teaching a computer to beat a human at Go was hard? There is no quantity of doctors' notes large enough to solve that great mystery of life.

Then there are forms, which pile all of the challenges into one place. Typed labels that have to relate to handwritten answers, deciphered separately and reassembled correctly.

One practical note before you start building: If you have any influence over the forms themselves, use it. Grid-style boxes force people to space out their letters and define a usable area for each field. If that's too limiting, keep your field boxes black (non-scan colors like red, pink or cyan can drop out completely in the pre-process), and your field labels above or to the left of the fields (not inside or touching the boundaries). Blank lines invite the sprawl that breaks everything downstream. Design with scaffolding wherever you can.

What is ICR, and how is it different from OCR?

Quick Answer: Intelligent Character Recognition (ICR) is a neural network trained on handwriting examples rather than font definitions, so it can read writing it has never seen before. Optical Character Recognition (OCR) is based on matching the shape of a letter and expected characteristics - based on printed fonts.

Also of note, this is ever evolving. AI-powered OCR can sometimes pick up handwriting pretty well. As AI continues its expected exponential growth, will be interesting to see where this all ends up.

But as of 2026 as I write this, OCR and ICR each are the right tool for their different jobs, and there are many cases where you may need both. When you are building your self-hosted solution, make sure to review which engines are available. Tools like the Apryse Server SDK have lots of options (a few flavors of OCR and ICR), which make it easier to test multiple options out at one time.

Let's take a look at a simple Apryse SDK ICR implementation.

from apryse_sdk import *

PDFNet.Initialize(LicenseKey)
PDFNet.AddResourceSearchPath("../../../ICRModule/Lib/")

if not HandwritingICRModule.IsModuleAvailable():
    print("Handwriting ICR module not available. Download it from https://docs.apryse.com/core/guides/info/modules#handwriting-icr-module")
else:
    doc = PDFDoc(input_path + "intake_form.pdf")

    opts = HandwritingICROptions()
    opts.SetPages("2-3")

    # Run ICR and apply the result as hidden text
    HandwritingICRModule.ProcessPDF(doc, opts)

    doc.Save(output_path + "intake_form_searchable.pdf", SDFDoc.e_linearized)
    doc.Close()

PDFNet.Terminate()

Full and beautiful sample, complete with C#, C++, Java, PHP, and all the favorites: https://docs.apryse.com/core/samples/icrtest

SetPages is doing quiet work here. Running ICR only on the pages that contain handwriting is faster. Skip sections like the signature box and use OCR on typed pages. (Although, it might be an entertaining exercise to see if what signatures come out as. lol)

Developer note: Apryse ICR is a separate module you download from https://docs.apryse.com/core/guides/info/modules#handwriting-icr-module, and it maps to its own add-on to your Server SDK license. If you're using this, make sure to have it on your list of topics for sales.

When should you use a vision LLM instead?

Quick Answer: When volume is not huge and your documents are allowed to leave your network, then you can't beat the big players in the game. Vision LLMs are part of the AI ecosystem that is supposed to keep improving exponentially. Everything is subject to change quickly. Keep testing.

Because if the growth and change in the industry, nothing I type can be counted on for any real length of time. But here are a few high level considerations:

Reach for a vision LLM when:

Legal discovery, a few hundred pages. Low volume contains the cost, and the documents are public.
Historical archives and freeform cursive, where searching beats structuring. Broad training data copes with wildly unpredictable inputs, and you want a searchable layer rather than structured fields.

Reach for self-hosted recognition when:

Medical intake forms under HIPAA. Data cannot leave the network. That is the whole decision.
10,000 forms a night. Per-page costs become significant enough to be worth the extra setup.
Anything an auditor will review. Recognition is deterministic. Same document, same output, every time.

There is one comparison that needs no benchmark. A recognition engine is deterministic: same document, same output, every time. A generative model is not. If you have an auditor involved with your output, making sure you know the output is repeatable is important.

Healthcare keeps showing up for a reason. Handwritten intake forms, prescriptions and clinical notes are where patient data workflows pile up, and the time saving is measurable. A prospective multi-center study in Critical Care found OCR cut data entry time in intensive care units by a mean of 43.9%. Reported figures for ICR in claims and e-prescription workflows run as high as a 70% reduction.

In the end, there are a lot of numbers to throw around for these tools, and they are only as good as the time period they were printed. Technology is changing almost daily - usually improving these numbers for the better.

To sum up: manual data entry stinks. Make it easier, and both time needed and accuracy are better.

How do you get from a scanned form to structured JSON?

Quick Answer: ICR gets you a searchable PDF and a JSON file full of words and coordinates. It does not get you {"date_of_birth": "1985-03-14"}. Turning recognized words into named fields can take a few more steps.

That position data is the part people undervalue. Text alone is a wall of words. Working in the Apryse Server SDK, here's one approach to that work:

Find the fields. The Data Extraction module, run with the form engine, returns each field's position, type and a confidence score.
Convert those positions into zones. Field detection measures from the top-left. PDFs measure from the bottom-left. Subtract each Y value from the page height, or ICR will confidently read the wrong part of the page.
Run ICR on just those zones. Faster than the whole page, and it keeps the engine away from the signature box.
Apply the results to a clean template. Key-value extraction does not work on scanned documents, which is the gotcha that derails people. Apply the ICR output onto a blank copy of the form instead, at zero opacity.
Extract the pairs, then check the doubtful ones. Route anything below your confidence threshold to a person.

Roger Dunham's full worked example walks all of it in JavaScript, including the coordinate flip and the template trick.

It is a lot of steps for one form. That is the honest trade. You get a pipeline that runs entirely inside your own network, on documents that are not allowed to leave it. You pay for that in set up, but you also get to dial into exactly what you need.

What confidence threshold should you set?

Quick Answer: Every recognition engine returns a per-field confidence score alongside the text. Your threshold is the line below which a field stops going straight into the database and goes to a person instead. Around 90% is a common starting point, tuned against your own documents.

This is the mechanism behind human-in-the-loop, and it is worth being concrete about, because "we'll add review later" is how review never gets added.

Nothing is going to be 100% accurate. Set the threshold too high and you drown your reviewers in fields that were fine. Set it too low and wrong data lands in the record silently. The only way to find your number is to run a few hundred of your own documents, compare against ground truth, and look at where the errors actually cluster.

Two things that make the number easier to live with.

Set it before you build the pipeline, not after you have discovered the problem in production.
Measure your reviewers too, because people are not 100% accurate either.

Remember the goal is always "better", not perfect.

Where should you start?

Quick Answer: Test your worst handwriting first, decide the data residency question early because it usually settles the engine choice, and pick your confidence threshold before you build.

Start with your worst examples. The messy intake forms, not the tidy ones. Good scans are easy once the bad ones work.
Measure Character Error Rate and Word Error Rate on your own documents. Doesn't matter what anyone else's tests showed, only what you see on what you're working with at the time you are starting.
Check whether your data is legally allowed to leave your network. That usually decides between ICR and a vision model on its own.
Decide your confidence threshold before you build the pipeline, and design the review queue at the same time. Everyone will thank you later for planning this upfront.
Redesign the form if you can. Boxes beat blank lines.
Get a trial key. Why not start with testing Apryse? Every module is included in the 30-day trial with no page cap: docs.apryse.com/guides/get-started. Sample code for ICR is at docs.apryse.com/core/samples/icrtest.

With good recognition in place, all of those pieces of paper become sources your systems can actually use. Every visit your oldest client made is exhaustively documented and, better still, searchable. Your filing cabinets turn into a nostalgic history of useful data you can reach in seconds.

Happy Coding!

How does AI text recognition work? OCR, ICR and the Python pipeline that feeds your LLM

Julie Love — Wed, 09 Sep 2026 18:27:13 +0000

Quick Answer: AI text recognition converts images of characters into machine-readable text, and it runs before anything an LLM does. Classic OCR matches shapes against known fonts. AI-powered OCR replaces that template matching with a neural network. ICR is trained on handwriting. This is step 1 of 5, and arguably your most important step. Downstream tools can't repair what step 1 gets wrong.

AI is currently center stage, in the spotlight, on every single space anyone can half-correctly call a stage right now. The most shiny of new toys even us geeks have seen in ages.

So as is quite fitting with the time, the AI step in a document workflow gets all the attention. The recognition step gets glossed over, that is, until the answers start coming back wrong and it's time to dig into the why.

Here is what catches people up: they blame it on hallucinations. But the recognition step is just doing its job - reporting what the characters look most like on an imperfect document.

How does AI text recognition actually work?

Quick Answer: There are three major players in the game. Classic OCR compares pixels against known letter shapes and picks the closest match. AI-powered OCR swaps that template matching for a neural network, still aimed at print but far more forgiving of bad scans. ICR is trained on real handwriting, so has more capacity to correctly analyze every new handwritten letter instance.

Classic OCR. Optical Character Recognition assumes a standard font on a copy-machine-quality image. It expects the page to line up with its finite set of letter and font definitions. Think hall monitor with clipboard and a stopwatch - they get things done and keep it efficient, but you better fall in line with the exact expectations. With a clean print, it is better than 99% accurate - tough to beat for the job.
AI-powered OCR. Same target as classic OCR, but a neural network does the deciphering instead of a template. (think feature detection as opposed to rigid patterns) It handles the bad scans, complex layouts and unusual fonts that break a template matcher. So this is probably that hall monitor you liked a bit better - can look the other way on small exceptions, but largely still keeps things running as expected.
ICR. Intelligent Character Recognition learns character shapes from examples rather than matching templates. Lots and lots and lots of examples, which is what makes it good at educated guesses on handwriting. In the halls, this monitor knows that no two kids are exactly the same, leaving room for self-expression in an otherwise rigid rule book.

What works best? Only you, your examples and a bunch of testing can decide that. So having all of these options in one place, like the Apryse Server SDK, is definitely an advantage.

Apryse's default OCR module moved to deep learning neural networks in version 12.0, released July 2026. That brought roughly 16% better word recognition, much better tolerance of low-quality scans and complex layouts, no GPU requirement, and - my favorite part - a jump from 6 supported languages to more than 80.

Default OCR, AI-powered since v12. For print with poor scans, complex layouts, or non-English pages. 80+ languages and the most versatile of the set. Licensed under the OCR add-on.
Alternative OCR. For clean print, where speed and lean hardware matter most. Runs 2 to 3x faster. Also the OCR add-on.
IRIS OCR. For disconnected text regions like magazine covers and CAD drawings, where it handles fragmented layouts. Separate IRIS OCR add-on.
Handwriting ICR. Anything written by hand, and the best handwriting results of the four. Separate ICR add-on.

Developer note: these are each separate modules you download from https://docs.apryse.com/core/guides/info/modules, and they map to specific add-ons for your Server SDK license. When you're ready for the call with sales, make sure to mention which items you're using.

Where does recognition sit in an LLM pipeline?

Quick Answer: Right at the front, before anything interesting happens. The pattern people now search for as OCR LLMs is really a pipeline, and recognition is step 1 of 5. Everything after it inherits whatever it produced before.

Recognition. The page becomes text.
Chunking. That text gets split into passages.
Embedding. Passages become vectors.
Retrieval. A question pulls back the passages that look relevant.
Generation. The model answers using what it retrieved.

Nothing downstream can repair a problem in step one. An embedding model has no way to know that "rnedication" was "medication" before the scan blurred, and a retrieval step cannot find a passage that was never extracted.

What happens when recognition output is noisy?

Quick Answer: It fails quietly rather than loudly, which is the worse of the two options. Five failure modes account for most of it, and not one of them throws an error.

Character-level corruption. One misread letter creates a token the model has never seen, so the passage embeds strangely and stops matching the questions it should match.
Phantom whitespace. Words split or run together, breaking exact-match retrieval and keyword search.
Broken reading order. A two-column page read straight across interleaves two unrelated arguments into nonsense.
Lost tables. Rows and columns flatten into a stream of digits, so a figure detaches from whatever it was measuring.
Missing content entirely. Handwritten fields that classic OCR could not parse simply are not there, and nothing flags their absence.

That last one is the quietest failure of the set. An empty field looks identical to a field the patient left blank.

How do you get OCR output into an LLM?

Quick Answer: A tool like Apryse OCR returns structured JSON or XML containing the recognized text and its position on the page. OCR text alone is a wall of words. Text plus coordinates is something a database, a rules engine or a retrieval pipeline can act on, because you can map any answer back to the exact spot it came from.

There are always about as many options to accomplish the same task as stars in the sky (the reason I'd argue that coding is art), but let's take a look at the basic OCR code in Python with Apryse.

from apryse_sdk import *

PDFNet.Initialize(LicenseKey)
PDFNet.AddResourceSearchPath("../../../OCRModuleWindows/Lib/")

if not OCRModule.IsModuleAvailable():
    print("OCR module not available. Download it from https://dev.apryse.com/")
else:
    doc = PDFDoc(input_path + "scanned_invoice.pdf")

    opts = OCROptions()
    opts.AddLang("eng")

    # Get the recognition result as JSON before it goes anywhere
    json = OCRModule.GetOCRJsonFromPDF(doc, opts)

    # Inspect, filter or correct here, then apply it back to the document
    OCRModule.ApplyOCRJsonToPDF(doc, json)

    doc.Save(output_path + "scanned_invoice_searchable.pdf", 0)

PDFNet.Terminate()

For more detail and other languages, check out the formal OCR Sample code.

Important not to gloss over the notes here, particularly: "Inspect, filter or correct here," GetOCRJsonFromPDF gives you the recognition result before it becomes a searchable PDF, which means this is the spot to add some checks. Filter low-confidence words, strip special characters or reject a page outright before any of it reaches your chunker. If you are feeding an LLM, that inspection point is the best way to ensure higher quality or know when something needs more human review.

Why not just send the page to a multimodal model?

Quick Answer: Sometimes you should. If you have neither security nor cost-saving concerns, they are great. I've seen some really impressive accuracy. Unfortunately, the great result is not always repeatable and can get expensive. When deployment control, cost and predictability can't be compromised, that's the reason to run recognition yourself.

Your documents leave the building. For patient records or anything with a data residency requirement, that is where the conversation ends. No cloud API runs inside an air-gapped network.
Cost scales with pages. Fine for 50 documents. Budget line item at 50,000.
It may not give the same answer twice. Recognition engines are deterministic. Generative models are not, which matters when an auditor asks why one document produced two different records.
Latency. A round trip to someone else's server adds time you may not have.
No coordinates. A model hands you text. A recognition engine hands you text plus exactly where on the page it came from.

So just to be clear, this can be a big lift to put together. ChatGPT, Gemini or Claude tools will return results with less effort. But when you need to control everything, it's time to start building.

Where should you start?

Quick Answer: Test your worst documents first and measure the error rate on your own files. Settle any data residency questions before you pick an engine, because it may decide for you.

Start with your worst examples. Bad scans are the real test. The good ones are easy once worst-case is optimized.
Measure the error rate on your own documents. Character Error Rate and Word Error Rate are the standard measures, and no vendor's published figure tells you what yours will be.
Check whether your data is legally allowed to leave your network. That usually settles the engine question on its own.
Match the module to the page. Print, handwriting and collage layouts want different engines, and you may need several inside one project. Use the right tool for each job.
Read the recognition output before you read the model's answer. Most pipeline bugs live upstream of the part everyone is looking at.

If you've decided that you are building, definitely give Apryse a try. Get a trial key at docs.apryse.com/guides/get-started. The 30-day trial includes every module mentioned here, with no page cap - so you can put your worst scan through all four before you commit.

Happy Coding!

Exporting OCR Data to JSON with Apryse

Hanna Miller — Thu, 03 Sep 2026 15:28:10 +0000

Summary: OCR technology has revolutionized the handling of printed documents by converting images of text into machine-readable data. However, this data is often unstructured and hard to analyze. Converting OCR output into a structured format like JSON makes the text searchable, accessible, and easy to integrate with various applications. This enables efficient data analysis, automation, and archiving, unlocking the value of previously inaccessible information.

Introduction
Exporting OCR data to JSON with Apryse converts unstructured, machine-readable text into a structured format that preserves not just the extracted words but also metadata like font size, orientation, and position within the document. This makes the output searchable, easy to integrate with other applications, and simple to store, analyze, or feed back into automated workflows.

The process uses the Apryse OCR Module within the Server SDK, which runs entirely on your own infrastructure so documents never leave your environment. After installing the module, a single function call, getOCRJsonFromImage, extracts the OCR results directly to JSON. The output is organized as nested arrays covering pages, paragraphs, lines, and words, each carrying its own metadata. From there, the structured data can be stored for later use, fed into another application or database, or applied back onto the original document to correct or update it.

Optical Character Recognition (OCR) technology has transformed how we handle printed documents. Converting images of text into a machine-readable form often results in unstructured and difficult to analyze data. A powerful solution is to structure this OCR output into a format like JSON (JavaScript Object Notation). OCR to JSON extraction makes text searchable, accessible, and easy to integrate with various applications, enabling efficient data analysis, automated entry, archiving, and more. Ultimately, OCR to JSON unlocks the value of previously inaccessible information.

In this blog, we’ll explore JSON, exporting data to JSON using an OCR SDK, how the Apryse OCR SDK will be your top choice, and the process to export OCR to JSON.

JSON

JSON, a lightweight data-interchange format, is easily usable by humans and machines. Built on a subset of JavaScript, and drawing familiar conventions from languages like C, C++, C#, Java, JavaScript, Python, and others, JSON offers an ideal and flexible way to exchange data. Its straightforward structure requires no specialized knowledge or tools for analysis and interpretation.

Apryse OCR

The Apryse OCR Module adds enterprise-grade text recognition to the Apryse Server SDK, ready to transform your document workflows.

Key Features

Handles various document types, including tables, multiple languages, and different text orientations.
Includes preprocessing steps such as deskew and despeckle that you apply before recognition.
Efficiently handles high-volume workflows.
Easily integrated into existing systems and server environments.
Can be fine-tuned for optimal performance by adjusting processing parameters.
Runs entirely on your own infrastructure, so documents never leave your environment.

Developers can fine-tune the OCR engine for optimal performance by adjusting processing parameters to meet the needs and requirements of any project.

From reduced costs and increased efficiency to improved accessibility and customized data output, the Apryse OCR offers a comprehensive suite of benefits for your business. If you’re looking for a practical example, see how to create a .NET Core cross-platform OCR application.

OCR Engines

The Apryse Server SDK offers more than one OCR module, so you can match the recognition engine to your document set rather than accept a single fixed path. The default module is built on deep learning neural networks and covers a broad language set including CJK, Arabic, Cyrillic, and Latin-alphabet languages, the right starting point for most projects, and the one this blog uses. Alternative modules are available for workloads with existing accuracy baselines. If only one module is installed, the SDK uses it automatically; with more than one present, you select through the OCR options object. See the add-on modules documentation for the current list and installation steps.

Export OCR to JSON

JSON’s structured format makes it ideal for organized data storage and seamless exchange between applications and systems. When you export OCR to JSON, you not only preserve the extracted text but also include valuable metadata – information about the text’s appearance with the document, such as font-size, orientation, and more. This rich data set simplifies storage, access, and future use. Furthermore, the extraction process itself can be implemented with minimal code.

Step 1: Download and install the OCR module.

Step 2: Now let’s use OCR to extract the data to a JSON file.

JavaScript
async function main() {
// Setup empty destination doc
const doc = await PDFNet.PDFDoc.create();
const image_path = "path/to/image";
// Extract OCR results as JSON
const json = await PDFNet.OCRModule.getOCRJsonFromImage(doc, image_path, opts);
}
PDFNet.runWithCleanup(main);

Output Attributes
Now that we have our JSON file with the extracted OCR data, we can see the various attributes of the data. Output consists of nested arrays for pages, paragraphs, lines, and words. Pages have the following metadata:

Each word has the following metadata:

Sample JSON Output

Here we can see what the JSON output from OCR extraction could look like.

So, what do I do with the data?

Great question! Now that our data has been extracted, organized, and stored in a JSON file, we can explore its potential uses, such as:

Storing the dat

a for later use.
Using the data in another application, database, or system.
Applying corrected or processed data back onto the original inputdocument.

Conclusion

In conclusion, by utilizing the robust Apryse Server SDK's OCR Module to extract OCR data to JSON, businesses can unlock valuable information trapped within static formats. Streamlined by the OCR capabilities, this process makes data searchable and accessible and facilitates streamlined integration with various applications and workflows. When using Apryse’s OCR to JSON functionality, you can maximize efficiency, improve accessibility, and realize the full potential of your information.

Check out a demo of Apryse OCR module in action. Contact our sales team for any questions.

Need help setting up? Join our Discord community for support and discussions.

React-pdf vs Apryse WebViewer: Which Is Easier to Customize?

Hanna Miller — Thu, 27 Aug 2026 19:21:28 +0000

"Customizable" means different things depending on where you're starting from and for React developers choosing between react-pdf and Apryse WebViewer, that distinction shapes months of engineering time down the line. This post breaks down the real difference: react-pdf hands you a lightweight rendering foundation you build everything on top of, while WebViewer gives you a full document experience you customize instead. Including a real-world example of a team that outgrew the build-it-yourself approach, here's what to weigh before you commit.

Developers often compare react-pdf and Apryse WebViewer, a react-pdf alternative, when building React applications.

Both can be customized. The difference lies in what you are customizing.

React-pdf

React-pdf focuses on rendering PDF documents inside React applications. It intentionally provides a lightweight foundation.
Developers typically build their own toolbar, navigation, search, annotation experience, document workflows, and branding.
This approach offers maximum implementation freedom but places more responsibility on the application team.

Apryse WebViewer

Apryse WebViewer starts from a different philosophy. Rather than providing only rendering, it includes a complete document experience with a modular user interface.
Developers can customize colors and themes, branding, toolbars, menus, side panels, workflows, permissions, annotation behavior, and integrations.

Instead of building these capabilities from scratch, teams customize an existing foundation.

Which Is More Customizable?

The answer depends on what "customizable" means.

If customization means changing source code for a minimal viewer, react-pdf offers that flexibility.

If customization means creating a production-ready, branded document experience with minimal rebuilding, Apryse WebViewer provides substantially more functionality to customize from day one.

Real-World Example

Blue Voice initially built its application using an open-source React PDF viewer. As the product expanded across police departments, maintaining PDF functionality internally began consuming engineering time that could have been spent improving the company's core product. The team ultimately adopted Apryse WebViewer, allowing developers to focus on customer-facing innovation instead of maintaining document infrastructure. They later expanded their application with AI-powered document workflows built on top of the same platform.

Which Should You Choose?

Choose react-pdf if your application only requires PDF rendering and you expect to build the surrounding experience yourself.

Choose Apryse WebViewer if you want a customizable document platform that includes advanced capabilities while remaining flexible enough to match your application's design and workflows.

For many teams, the decision of react-pdf vs Apryse WebViewer is less about open source versus commercial software and more about whether they want to build document infrastructure themselves or customize an existing platform.

FAQ

Is react-pdf harder to customize than Apryse WebViewer?
Not harder but different. React-pdf gives full source-level control over a minimal viewer; Apryse WebViewer gives a full-featured, modular UI that's customized rather than built from scratch.

Can I migrate from react-pdf to Apryse WebViewer?
Yes. Teams commonly migrate once the surrounding experience they've built on react-pdf, such as toolbar, search, annotations, workflows, becomes more costly to maintain than adopting a platform that includes it.

Does Apryse WebViewer work well in React applications?
Yes. WebViewer integrates into React applications and provides the modular UI, annotation, and workflow capabilities react-pdf leaves to the development team to build.

Best React PDF Viewer Alternatives for Production Applications

Hanna Miller — Tue, 25 Aug 2026 14:53:50 +0000

React-pdf will get you PDF rendering fast, but for teams building production applications, the real question is what happens when your document requirements outgrow that lightweight foundation. This post lays out how react-pdf and Apryse WebViewer compare on the features that tend to surface as products mature: annotations, forms, redaction, signatures, and UI customization. With a quick-reference comparison table and a real migration story, it’s a practical read for anyone choosing a React PDF viewer with an eye on where their app is headed, not just where it is today.

Short Answer

If you need a basic PDF viewer in a React application, react-pdf (built on Mozilla PDF.js) is an excellent starting point.

If you need a viewer that can grow with your application — supporting advanced document workflows, extensive UI customization, annotations, redaction, signatures, and additional document formats — Apryse WebViewer is the stronger long-term choice.

The right decision depends less on whether a library is open source and more on how much functionality your application will eventually require.

Quick comparison

Which React PDF Viewer Is Most Adaptable?

If adaptability means the ability to customize your application’s document experience over time, Apryse WebViewer provides significantly more flexibility than many developers expect.

While react-pdf is open source, it intentionally provides a lightweight viewer. Development teams typically build their own toolbar, search experience, annotation interface, document workflows, and branding on top of it.

Apryse WebViewer approaches the problem differently. It includes a fully featured viewer while exposing a modular, themeable UI that developers can customize, extend, or replace without rebuilding core document functionality.

For many production teams, that means spending more time building product-specific features instead of document infrastructure.

The Hidden Cost of Starting Simple

Open-source libraries reduce licensing costs, but they do not eliminate engineering costs.

As applications mature, teams often need features such as:

Search
Annotation
Document comparison
Redaction
Digital signatures
Accessibility improvements
Workflow customization

Each additional requirement increases the amount of custom code that must be maintained.

Many organizations eventually decide that maintaining document infrastructure is not where they want to invest engineering effort.

Real-World Example

Blue Voice initially built its application using an open-source React PDF viewer. As the product expanded across police departments, maintaining PDF functionality internally began consuming engineering time that could have been spent improving the company’s core product. The team ultimately adopted Apryse WebViewer, allowing developers to focus on customer-facing innovation instead of maintaining document infrastructure. They later expanded their application with AI-powered document workflows built on top of the same platform.

Learn how Blue Voice uses Apryse WebViewer to deliver AI-powered policy access across 200+ police departments.

FAQ

Is react-pdf good enough for production?
Yes. For applications that only need reliable PDF rendering and basic viewing. Applications that require advanced workflows often find themselves implementing many features manually over time.

Is Apryse WebViewer customizable?
Yes. The UI is modular and themeable, allowing organizations to customize branding, layouts, workflows, and user experience without rebuilding a document viewer from scratch.

Which PDF viewer is better for enterprise applications?
For teams that expect document requirements to grow over time, Apryse WebViewer generally requires less custom infrastructure while providing a broader set of document capabilities.

DEV Community: Apryse

JavaScript Spreadsheet SDK: How to Embed Excel-Like XLSX Editing into Your React App

Introduction

Why Embed an Editor?

Spreadsheet SDK vs. Data Grid: Knowing What You Need

Comparing the Top JavaScript Spreadsheet SDKs

The Benefit of a Unified Document SDK

Common Use Cases

How to Embed Apryse Spreadsheet Editor into a React App

Prerequisites

Scaffold a React Project with Vite

Navigate to the New React Project

Integrate WebViewer

Copy Static Assets

Install WebViewer

Setting Up the App

What Can We Do Now?

FAQ

Conclusion

Additional Apryse Suggested Reads

How to Create a Browser-based Spreadsheet Editor Using TypeScript, React and Vite

Introduction

A few words on configuration

Step 1. Scaffold the app using create-vite

Step 3. Get ready to install WebViewer

Step 4 - Install WebViewer

Step 5. Create an HTML element where WebViewer will be mounted

Step 6. Instantiate WebViewer

Step 7. Solving issues with CSS

Where next?

Can you vibe code a DOCX editor for $200?

What does a weekend and $200 actually get you?

Why does every "can it also do..." request cost more than it sounds?

What if you don't control what is uploaded?

What is the round-trip problem?

Can you maintain code you have never read?

Is anyone actually gatekeeping this?

So when should you build it yourself?

Where should you start?

Self-hosted OCR without a cloud API: where Tesseract stops working

Where does Tesseract stop working?

What does "free" OCR actually cost?

What does a production OCR SDK give you that Tesseract does not?

Does self-hosting OCR solve compliance?

Where should you start?

Further reading

ICR handwriting recognition in Python: when do you need self-hosted instead of a vision LLM?

Why is handwriting so much harder to read than printed text?

What is ICR, and how is it different from OCR?

When should you use a vision LLM instead?

How do you get from a scanned form to structured JSON?

What confidence threshold should you set?

Where should you start?

Further reading

How does AI text recognition work? OCR, ICR and the Python pipeline that feeds your LLM

How does AI text recognition actually work?

Where does recognition sit in an LLM pipeline?

What happens when recognition output is noisy?

How do you get OCR output into an LLM?

Why not just send the page to a multimodal model?

Where should you start?

Further reading

Exporting OCR Data to JSON with Apryse

JSON

Apryse OCR

OCR Engines

Export OCR to JSON

Sample JSON Output

So, what do I do with the data?

Conclusion

React-pdf vs Apryse WebViewer: Which Is Easier to Customize?

React-pdf

Apryse WebViewer

Which Is More Customizable?

Real-World Example

Which Should You Choose?

FAQ

Best React PDF Viewer Alternatives for Production Applications

Short Answer

Quick comparison