--- site_search: "GET /ask?q={query} (read-only search over extend.ai and docs.extend.ai; returns links and quoted passages, not generated answers)" title: "The History of OCR: From Reading Characters to Understanding Documents" description: "How OCR evolved from 1910s reading machines to omni-font software, template capture, neural networks, and today's layout-first document processing." author: "Devin Logan" category: "Engineering" published: 2026-10-28 canonical: https://www.extend.ai/resources/history-of-ocr --- # The History of OCR: From Reading Characters to Understanding Documents > Search this site and the docs: [`/ask?q=…`](/ask?q=webhook+retries) returns matching pages from extend.ai and docs.extend.ai, with quoted passages. Optical character recognition (OCR) converts printed or handwritten text in scanned documents, photos, and PDFs into text a computer can search and edit. Early OCR machines read typewritten letters one at a time. Today, OCR is one step in a larger process: document processing systems like Extend first identify what's on a page, such as paragraphs, tables, and figures, and then route each one to specialized models. ## Early OCR precursors Before computers, inventors built machines that converted printed text into sound, telegraph code, and other forms. These devices relied on two ideas that still underpin OCR today: using light sensors to detect the shapes of characters, and comparing those shapes against known patterns. In 1913, Irish physicist Edmund Fournier d'Albe invented the [optophone](https://en.wikipedia.org/wiki/Optophone), a device that converted printed text to a series of audible tones using selenium photosensors. Blind users could interpret these tones to read. Initial iterations of the machine were [very slow](https://soundstudiesblog.com/2015/01/05/optophones-and-musical-print/), around one word per minute; later users could achieve up to around 60 words per minute. In 1914, physicist Emanuel Goldberg built a machine that read characters and converted them into telegraph code. He later invented a photoelectric ["Statistical Machine"](https://people.ischool.berkeley.edu/~buckland/statistical.html) for searching microfilm records, and IBM licensed the patent soon after it was granted in 1931. In 1929, [Gustav Tauschek](http://www.computer-timeline.com/timeline/gustav-tauschek/) patented his Reading Machine, a mechanical device that recognized printed text using templates and a photodetector. **Early OCR precursors** Video: None of these early machines were practical for business use, though. They were slow, worked only under controlled conditions, and existed mostly as patents and prototypes. ## OCR for commercial use Making OCR commercially viable meant limiting which characters machines had to read and standardizing how text was printed. In 1951, cryptanalyst David H. Shepard built and patented a machine he called ["Gismo"](https://www.historyofinformation.com/detail.php?entryid=885) that read typewritten letters and converted them into a computer-readable format. The first version recognized 23 letters of the alphabet, and an improved version later read all 26. In 1952, he founded Intelligent Machines Research Co. (IMR) to commercialize his invention. In November 1965, the Detroit Post Office put an [OCR address reader](https://postalmuseum.si.edu/the-20th-century-mechanization-and-early-automation) into service to speed up mail sorting; nine post offices were using them by 1970. The machine read the city, state, and ZIP Code line of typed addresses and sorted each letter into one of 277 pockets. (The USPS still sorts mail with OCR today. Its machines now read [around 98% of handwritten addresses](https://facts.usps.com/98-percent-of-hand-addressed-letters/).) In the 1960s, standardized fonts made printed text easier for machines to read. [OCR-A](https://en.wikipedia.org/wiki/OCR-A), issued in 1966 to U.S. Bureau of Standards specifications, was easy for machines but hard for people to read. [OCR-B](https://multimediaman.blog/tag/ocr-b/), designed by Adrian Frutiger in 1968 for the European Computer Manufacturers Association, worked for both and became an international standard in 1973. Modern OCR doesn't need special fonts, but OCR-B is still printed on barcodes and passports. **OCR for commercial use** Video: These early commercial systems still only worked for a narrow subset of printed documents, in specific fonts or with a limited set of characters. The first postal OCR machines, for example, could read only the 80 most common of the roughly 600 typefaces in use. ## Reading any font Through the 1970s and 1980s, OCR developers worked to remove limitations on fonts and characters, so machines could read most ordinary printed documents. In 1974, [Ray Kurzweil](https://www.invent.org/inductees/raymond-kurzweil) developed the first omni-font OCR software, which could read text in virtually any font. In 1976, he introduced the Kurzweil Reading Machine, the first print-to-speech reading machine for blind users. In 1988, Caere Corporation released [OmniPage](https://en.wikipedia.org/wiki/OmniPage), one of the first OCR programs to run on personal computers. It could read multiple typefaces without first being trained on them. ABBYY FineReader followed in 1993, bringing OCR for multiple languages to PCs. **Reading any font** Video: Handwriting continued to be a harder problem. As late as 1995, USPS sorting machines could automatically read only about 2% of handwritten addresses. ## Template-based capture For printed documents, the next challenge after converting pages to text was getting specific data out of them. The dominant method through the 1990s and 2000s was [template-based (zonal) OCR](https://en.wikipedia.org/wiki/Forms_processing). An operator drew boxes on a sample document to mark where each field appeared, such as the invoice number in the top right or the total at the bottom. The software then ran OCR only inside those boxes on every matching document. Template-based OCR worked well for documents with fixed layouts, such as tax forms and standardized applications. It struggled with documents like invoices, where every vendor uses a different layout. Each new layout needed its own template, and a vendor redesigning its invoice could break extraction. Capture platforms later added features to tolerate some variation, such as finding a field by nearby label text (like "Total") instead of exact coordinates, or learning a field's position from corrected examples. These still depended on where fields appeared on the page, and maintaining templates remained an ongoing cost. ## OCR at internet scale While enterprise capture tools focused on forms, OCR spread well beyond the office in the 2000s and 2010s. Google and others used it to digitize millions of books and newspapers, and smartphones made it available to consumers. In 2004, Google began scanning the collections of major research libraries, including Harvard, Stanford, and Oxford. By 2019, [Google Books](https://en.wikipedia.org/wiki/Google_Books) had digitized more than 40 million volumes. In 2005, HP and the University of Nevada, Las Vegas released [Tesseract](https://en.wikipedia.org/wiki/Tesseract) as open-source software. Google sponsored its development from 2006 onward, and it became the most widely used free OCR engine. Projects like Google Books also exposed OCR's limits. Old books and newspapers contained faded ink, unusual typefaces, and damaged pages that software couldn't read reliably. In 2007, researchers at Carnegie Mellon launched [reCAPTCHA](https://en.wikipedia.org/wiki/ReCAPTCHA) to address this. Each challenge showed users two words: one with a known answer, to verify the user was human, and one that OCR had failed to read. The human answers became the transcription for the second word. reCAPTCHA helped digitize the New York Times archive, and Google acquired it in 2009 to support Google Books. OCR also moved onto phones. In 2009, [USAA](https://www.nytimes.com/2009/08/10/technology/10check.html) became one of the first banks to let customers deposit checks by photographing them with a smartphone. [Google Lens](https://techcrunch.com/2017/05/17/google-lens-will-let-smartphone-cameras-understand-what-they-see-and-take-action/) (2017) and [Apple's Live Text](https://techcrunch.com/2021/06/07/apples-live-text-lets-you-interact-with-text-in-your-photos/) (2021) applied the same idea to consumer products, letting users select and copy text from any photo. **OCR at internet scale** Video: ## Neural networks and document understanding Features like Live Text rely on neural networks, an approach that took decades to become practical. Before the 2010s, most OCR used rules and features that engineers designed by hand. The neural network approach dates back to 1989, when [Yann LeCun](https://en.wikipedia.org/wiki/Yann_LeCun) and his colleagues at Bell Labs trained a convolutional neural network to read handwritten US ZIP codes. Instead of being told what to look for, the network learned to recognize characters directly from labeled examples. In 1998, LeCun, Léon Bottou, Yoshua Bengio, and Patrick Haffner published "Gradient-Based Learning Applied to Document Recognition," which introduced the [LeNet-5 architecture](https://en.wikipedia.org/wiki/LeNet). By the late 1990s, a check-reading system built on this architecture was reading more than 10% of checks deposited in the US. Neural networks didn't become the standard for OCR until the 2010s, when larger datasets and faster hardware made them practical to train at scale. In 2018, Tesseract 4 switched to a [Long Short-Term Memory (LSTM)](https://www.ibm.com/think/topics/lstm) neural network that recognizes whole lines of text instead of individual characters. Neural networks also made it possible to model the layout of the page instead of just its characters. In 2019, Microsoft researchers introduced [LayoutLM](https://www.microsoft.com/en-us/research/articles/revolutionizing-document-ai-with-multimodal-document-foundation-models-2/), a model that combined text, position, and image information to understand document structure. Donut (2022) was a model that didn't use OCR at all, instead converting directly from pixels to structured output. **Neural networks and document understanding** Video: Around the same time, the industry converged on a name for this combination of tools: [intelligent document processing (IDP)](https://www.ibm.com/think/topics/intelligent-document-processing). The term covers systems that use OCR alongside layout analysis and machine learning to classify documents and extract specific fields instead of producing a page of raw text. A typical printed page contains a few thousand characters, so OCR with 99% character accuracy still makes dozens of errors per page. Even a perfect transcription only produces text. It doesn't identify which value is the invoice total or which table cells belong to the same row, and for most business documents, those are the details that matter. ## Today: OCR and AI OCR made decades of document automation possible, and for simple jobs, such as making a scanned archive searchable, it's still usually enough on its own. Automating a business process or building an agent on top of documents is a different problem, though. Those systems need to understand how pieces of text relate to each other, and OCR wasn't designed for tables, forms, or handwriting ([layout-first APIs vs. traditional OCR](https://www.extend.ai/resources/layout-first-apis-vs-traditional-ocr) covers the difference in detail). Today, general-purpose AI models like GPT, Claude, and Gemini can [read document images directly](https://www.extend.ai/resources/ocr-and-ai-vision-language-models-replacing-text-recognition). They handle varied layouts much better than templates did. On their own, though, they can misread values or return fields in inconsistent formats, and they don't report how confident they are in each field. As a result, modern document processing systems built for production use often [start with layout](https://www.extend.ai/resources/why-layout-matters). Extend runs a layout model on every document before any other processing. The layout model identifies the components of a page, such as paragraphs, tables, form fields, and figures. Specialized vision models trained in-house, along with frontier models, then parse each component and output structured JSON with a confidence score for each field. High-confidence fields go straight into systems like ERPs or loan origination software, and low-confidence fields are routed to human review. On [RealDoc-Bench](https://www.extend.ai/resources/realdocbench), a public benchmark of 581 real-world documents, Extend's layout-first parser scores 95.7% field-level accuracy on document Q&A. **Today: OCR and AI** Video: [Try Extend](https://dashboard.extend.ai/demo) on your most complex documents today. ## FAQ ### Who invented OCR? No single person invented OCR. Early precursors include Edmund Fournier d'Albe's optophone (1913), Emanuel Goldberg's character-reading machine (1914), and Gustav Tauschek's Reading Machine patent (1929). David H. Shepard built one of the first commercial OCR machines, "Gismo," in 1951, and Ray Kurzweil developed the first omni-font OCR software in 1974. ### What is the difference between OCR and intelligent document processing (IDP)? OCR converts an image of text into machine-readable characters. Intelligent document processing uses OCR alongside layout analysis and machine learning to classify documents and extract specific fields, such as an invoice total or a policy number, instead of producing a page of raw text. ### Is OCR still used today? Yes. OCR is still usually enough on its own for simple jobs like making a scanned archive searchable, and USPS machines use it to read around 98% of handwritten addresses. In modern document processing, OCR is one step inside a larger pipeline that also models layout, tables, and fields. ### Why isn't OCR alone enough for business documents? A typical page has a few thousand characters, so OCR with 99% character accuracy still makes dozens of errors per page. Even a perfect transcription only produces text: it doesn't identify which value is the invoice total or which table cells belong to the same row. ### Can AI models like GPT, Claude, and Gemini replace OCR? They can read document images directly and handle varied layouts much better than templates did. On their own, though, they can misread values, return fields in inconsistent formats, and don't report how confident they are in each field, so production systems pair them with layout models, confidence scores, and human review. ## Related reading - [Best OCR APIs for Complex Documents in 2026](https://www.extend.ai/resources/best-ocr-apis-for-complex-documents) - [Top Vision AI Document Processing Tools for Complex Layouts (February 2026 Update)](https://www.extend.ai/resources/vision-ai-document-processing-tools-complex-layouts) - [Pytesseract Complete Guide: Master OCR in Python (October 2025)](https://www.extend.ai/resources/pytesseract-guide-ocr-limits-alternatives) - [How GPT-5 Performs on Real World Documents](https://www.extend.ai/resources/how-gpt-5-performs-on-real-world-documents) - [Best Handwriting OCR Tools & Software in February 2026: Complete Guide](https://www.extend.ai/resources/best-handwriting-ocr-tools-business)