Text Extraction in the Browser: 9 File Types Benchmarked

FileConcat reads every file in the browser it was dropped into, with no upload and no GPU. Version 2.1 replaced most of its readers. We ran public benchmarks on both versions.

Level with the best server tools where a file stores its own text, behind the GPU readers where text has to be recognised from a scan or a voice.

Higher is better, except word error. Speech is English / Turkish. The Tika ceiling is the most two good readers agree on those files. Word and Excel 97-2003 files scored the same in both versions.

Half way. 2.1 passes more of olmOCR-bench's tests than any reader without a GPU that we ran, and none of them writes math.

The jump from 2.0 is columns and tables: 2.1 keeps a two-column page in reading order and a table's cells under their headings. A quarter of the score is equations written as LaTeX, which a text layer cannot give, so every reader without a vision model scores zero there.

How it reads: LiteParse on pages with a text layer, OCR on pages without one.

Yes, for a page saved from Chrome. 2.0 bundled the whole HTML source, markup included.

2.1 lands one point under Mozilla Readability, the engine it runs, and three under the best server extractor. Firefox does not mark a saved page with its address, so a page saved there still goes the 2.0 way.

How it reads: Chrome's "saved from" mark, then Mozilla Readability, then Markdown.

Every Office format we tested reads in 2.1, at about the agreement two good readers reach.

Word 4-gram F1 x 100 against Apache Tika 3.3.2. The ceiling is Tika scored against itself on a LibreOffice-converted copy, the most two readers agree here. Office files have no public answer key, so agreement with a mature reader stands in for one.

How it reads: SheetJS for workbooks, a reader of its own for 97-2003 files, anydoc for rtf, officeparser for the rest, each with a second reader when the first returns nothing.

All but one, ahead of both archive libraries run on their own.

The one miss is a zip inside a zip, which is not opened. On libarchive's own rar and 7z test files, damaged and encrypted ones included, every file finished without a crash or a hang.

How it reads: zip, tar and gz in JavaScript, bz2, xz, rar and 7z through 7-Zip compiled to WebAssembly.

Kindle books and video. Both now read, a subtitle track word for word.

Speech is the weakest row. English runs on Moonshine base, a 66 MB model. Every other language runs on Whisper small, 244 MB, and the Turkish sample is two videos.

How it reads: the subtitle track on drop, speech and on-screen text only when you ask.

On three kinds of file, and each has a way around it.

1. Scans and math. The GPU readers at the top of the PDF chart are vision models a hundred times larger than the OCR model a laptop can run. For a scan you need exact, run it through one and drop the text it returns.
2. Web pages saved by Firefox. Save the page again from Chrome, or paste the article into a text file.
3. Speech that is not English. Keep a subtitle track in the file when there is one. It is read exactly and costs nothing.

Every format FileConcat reads, and how, is on the formats page.

Every file was dropped into FileConcat 2.1's production build in headless Chromium, the way a visitor drops it, and the text was taken from the downloaded Plain bundle. Each benchmark's own scorer did the scoring.

Chromium ran with an English or Turkish language setting, matching each video's speech, since that setting picks the speech and OCR model. Documents went in batches of up to 20 from one folder. A PDF that came back without text was dropped again alone, because FileConcat reads at most three scans per drop by itself. Archives and videos went one per drop.

The first Turkish run came back empty: the first transcription in a session ignored the browser's language and used the English model. That was fixed before the Turkish rerun. The English rows were not rerun.

Web pages are scored three ways, because the bundle adds lines the benchmark counts as noise.

Office files were measured in two sets: 587 modern files converted to the old formats by LibreOffice, scored against Tika on the original, and Apache POI's own test files. The table above uses the converted set for doc, xls, ppt and rtf and POI's files for xlsx and xlsb. On POI's files, 2.1 scored doc 74.5 (99 files), xls 74.8 (241), ppt 78.6 (71), docx 66.5 (64), pptx 55.9 (55) and xlsm 52.5 (7). Files with fewer than 20 reference words were not scored.

Every published extraction benchmark we found runs its readers natively, and most are written by the vendor of the tool that wins them. We found no measurement of extraction inside a browser, for any format.

The sources contradict each other where it matters here. LiteParse scores 39.6 on olmOCR-bench in its own README and 20.4 in Marker's, with OCR off in both. We ran every reader on our side under the same scorer, so a gap between two of our rows is not a gap between two harnesses.

• One browser. Chromium only. Firefox and Safari decode audio and video differently.
• No timing. Runs were on a desktop, so no speed figure is published. A laptop is slower.
• 2.0 ran in Node. Its rows are its extraction code run outside the browser. For 2.1, seven of the nine Office figures with a Node run matched the browser to the third decimal and the other two were within 0.012, so the two settings read the same.
• Small speech samples. Turkish is two videos. Its 32.4% is a direction, not a leaderboard figure.
• Agreement is not truth. Tika keeps headers, footers and comments some readers drop on purpose, and LibreOffice wrote every converted file.
• Archives favour 7-Zip. 7-Zip wrote the 7z variants and reads them in FileConcat. rar has no keyed set, since only WinRAR writes it.
• Weak and small: a Word 6 file scored 0, since only Word 97 and later is read, and two dotx templates scored 0.9.
• Not measured: layout beyond the benchmarks' own tests, email, encrypted files.

Build the web app and serve it, then drop a corpus through it.

pnpm build
cd apps/web && pnpm vite preview --port 4719 --strictPort
node packages/cli/scripts/measure-live-build.mjs http://localhost:4719/ <corpus dir> out.json
node packages/cli/scripts/measure-live-build.mjs http://localhost:4719/ <pdfs dir> out.json --olmocr <candidate dir>
node packages/cli/scripts/measure-live-build.mjs http://localhost:4719/ <video dir> out.json --transcribe

Score with packages/cli/scripts/score-against-reference.py (Office, ebooks), score-video.py (video), olmOCR-bench's python -m olmocr.bench.benchmark at commit f7cfe4c (PDF) and the article benchmark's evaluate.py (web pages). The archive and video test sets are written by build-archive-corpus.py and build-video-corpus.py in the same folder, with a fixed seed.

Can a browser extract text from a PDF without uploading it? Yes. FileConcat 2.1 reads the text layer in the browser and runs OCR on pages that have none. On 1,403 benchmark pages it scored 40.0, against 38.9 for LiteParse run alone and 82.4 for olmOCR 2 on a GPU.

How accurate is in-browser OCR? Good enough to search and summarise a scan, not good enough for math or degraded typewritten pages. The GPU readers that lead the benchmark are far larger than anything a browser can load.

Can I get text out of a saved web page? Yes, if it was saved from Chrome. On 181 benchmark pages the article text matched at 0.937 F1, one point under Mozilla Readability. A page saved by Firefox is bundled as HTML source.

Does it read old Word, Excel and PowerPoint files? doc, xls and ppt from Word 97 onward, plus rtf. Agreement with Apache Tika was 0.63 to 0.79, about what two good readers reach. Word 6 and older is not read.

Can it transcribe a video? On request. A subtitle track is read exactly and at once. Without one, speech is transcribed in the browser after a one-time model download: 66 MB for English, 244 MB for any other language.

• Poznanski, J. et al. "olmOCR 2: Unit Test Rewards for Document OCR." Allen Institute for AI, 2025. arXiv:2510.19817
• Zyte. Article extraction benchmark. github.com/scrapinghub/article-extraction-benchmark
• Jeffries, N. et al. "Moonshine: Speech Recognition for Live Transcription and Voice Commands." 2024. arXiv:2410.15608
• Hugging Face. Open ASR Leaderboard. huggingface.co
• LlamaIndex. LiteParse. github.com/run-llama/liteparse
• Datalab. Marker. github.com/datalab-to/marker
• Apache Tika. tika.apache.org