瀏覽器端本地 OCR 完整教學：Tesseract.js、PaddleOCR、TrOCR 三方案實作與零成本部署

最近我們在內部做幾個客戶的客製化系統時，碰到同一道牆——客戶想要做文字辨識（OCR），但文件本身敏感到不能上雲。一份是醫療客戶的病歷掃描檔，另一份是建設公司的合約頁。雲端 OCR API 報價漂亮、準確度也夠，但「文件不出本機」這條紅線一畫下來，整個雲端方案全部出局。

於是我們開始研究第二條路：把 OCR 模型直接搬進使用者的瀏覽器，從上傳那一刻到辨識結果出來，整個過程都在本機跑完，伺服器只負責下發模型檔。沒有 API 帳單、沒有上傳延遲、沒有資料外流風險——前提是這條路真的跑得動。這篇就是那段研究的整理：技術可行嗎、有哪幾條路線、各自的天花板在哪、真的零成本嗎、什麼情況下你該選它、什麼情況下乖乖用雲端 API。

從 2025 年下半到 2026 年，瀏覽器端 AI 推論的基礎建設出現了三個關鍵節點。第一個是 WebGPU 在 2025 年 11 月跨瀏覽器預設啟用，ddevtools 統計 顯示全球瀏覽器覆蓋率達 82.7%；第二個是 2026 年 2 月釋出的 Transformers.js v4，把 200+ 模型架構與 1,200+ 已轉換模型搬進瀏覽器；第三個是 Tesseract.js v6 全面改寫記憶體管理與執行時效能。三件事疊起來，瀏覽器端 OCR 從「玩具」變成「可上線」。

為什麼把 OCR 跑在瀏覽器：四個真正的理由

不要先談技術選型，先問「這條路有沒有解決問題」。瀏覽器端 OCR 不會比 Google Cloud Vision 準、不會比 Azure Computer Vision 快、不會比 AWS Textract 規模化。它真正解決的是雲端方案處理不了的四個問題——隱私、規模化成本、離線需求、即時體驗。下面一條條拆。

理由一：資料不能離開本機

醫療病歷、法律合約、人事資料、財務報表、身分證件——這些文件碰到雲端 OCR API 就立刻撞合規牆。台灣的個資法、歐盟 GDPR、美國 HIPAA 都對「個人資料境外傳輸」有限制，把客戶身分證影像送到 AWS Textract 是行得通的（只要走台北 region 並簽 DPA），但很多企業客戶根本不接受「文件離開公司網路」這件事本身。我們在做 #3 醫療客戶系統時就遇過——醫院 IT 的紅線是「病歷影像不能上 public cloud，連 region 在台灣的都不行」。

瀏覽器端 OCR 的好處：辨識在使用者裝置上完成，你的伺服器只看到辨識「結果」（甚至連結果都不必看），原始影像從來沒有離開過使用者的電腦。對合規會議、稽核問答、ISO 27001 控制項，這是最容易解釋的架構。

理由二：API 費用會在規模化時暴增

雲端 OCR API 看起來便宜——Google Cloud Vision 每 1,000 頁 USD 1.5、AWS Textract 每 1,000 頁 USD 1.5（基本）到 USD 65（含表格與表單欄位）、Azure 每 1,000 頁 USD 1（按 Google Cloud 官方定價頁）。看起來零頭，但實際算下來，一個發票辨識的 SaaS 產品如果每月處理 50 萬頁，光 OCR 成本就 USD 750-32,500，再疊上後端解析、儲存、流量成本。同樣的功能如果跑在使用者瀏覽器，這個帳單直接是 0。

理由三：離線可用

Progressive Web App、現場稽核工具、工地巡檢、機艙內掃描——這些場景有可能網路收訊極差。瀏覽器端 OCR 模型一旦透過 Service Worker 或 IndexedDB 快取下來，後續使用完全不需要網路。這是雲端 API 怎麼樣都做不到的事。

理由四：UX 即時性

從使用者按下「掃描」到看到結果，雲端 API 至少包含「上傳圖片 → 等待 API 回應 → 下載結果」三段。在 4G 網路上 5MB 的高解析掃描檔可能要 2-4 秒只是上傳。瀏覽器端 OCR 對中等大小文件可以做到 1 秒內出結果，對使用者體驗的影響是質變不是量變。

三條技術路線完整對比

瀏覽器端 OCR 目前有三條主流路線，技術棧、模型大小、適用場景都不一樣。先看總表，再進去個別拆解。

資料來源：Tesseract.js 官方 performance.md、PaddleOCR.js GitHub repo、Hugging Face Transformers.js 文件。實際速度取決於使用者裝置與圖片大小，數字為一般筆電（M2 / Ryzen 7）測試。

路線一：Tesseract.js v6 從零跑通繁體中文 OCR

Tesseract.js 是 Google Tesseract 5 引擎的純 JavaScript 移植，編譯成 WebAssembly 跑在瀏覽器。它的優勢非常清楚：零依賴、CDN 載入、100+ 語言、文件齊全。劣勢一樣清楚：手寫字辨識差、版面分析不如新的深度學習模型、中文準確率比 PaddleOCR 弱一截。

但對 80% 的「想做 OCR 但不太複雜」場景，Tesseract.js 就夠了。我們先把它跑通——這段程式碼可以直接複製貼上，做一個能辨識繁體中文 PDF/圖片的網頁。

最小可用範例（HTML + JS，無 build step）

  
  尚未開始
  


  

這段程式碼做了三件事：載入 Tesseract.js 6.x、用繁中+英文雙語言模型建立 worker、把使用者上傳的圖片丟進辨識。整段加 HTML 不到 50 行。第一次跑會下載約 18MB 的繁中模型（Brotli 壓縮），之後瀏覽器會自動快取，使用者下次進站幾乎零延遲。

效能調校：WebWorker 不會卡 UI

Tesseract.js 在瀏覽器內部已經會自動開一個 dedicated WebWorker，主執行緒不會被辨識計算卡住。但「初始化 worker」這個動作本身會載 wasm 檔（約 2.1MB Brotli 壓縮）跟語言檔。實務上建議在「使用者點開檔案選擇器」的瞬間就 prefetch 這些檔案，比等到「按下辨識」才開始載延遲少 1-2 秒。

更深入的優化可以用 SIMD 加速版本——Chrome >= 91、Firefox >= 90、Safari >= 16.4 都支援 WebAssembly SIMD，Tesseract.js v6 會自動偵測並啟用，文字辨識速度比非 SIMD 版本快 30-40%（依 Tesseract.js 效能文件）。

常見坑：CORS、Service Worker、SharedArrayBuffer

Tesseract.js 載入 wasm 檔需要瀏覽器允許 cross-origin requests。如果你把模型檔放自家 CDN（例如 Cloudflare R2 + Cloudflare CDN），記得：第一，回應 header 要包含 Access-Control-Allow-Origin：第二，如果要用 SharedArrayBuffer 加速（v6 預設啟用），頁面必須在 cross-origin isolation 環境，需要兩個 header：Cross-Origin-Opener-Policy: same-origin 跟 Cross-Origin-Embedder-Policy: require-corp。

這些 header 設好之前，Tesseract.js 也能跑，只是用 fallback 的 single-thread 模式，速度大概慢 50%。值得花 10 分鐘設定。

路線二：PaddleOCR 透過 ONNX Runtime Web 跑中文

Tesseract.js 在中文場景的天花板很明顯——拿一張正常的繁體中文發票丟進去，準確率大概 70-85%。對「掃完只要找關鍵字」的場景夠用，但要拿來自動填欄位（買方統編、總金額、品項清單）就會被同事抱怨「校稿的時間比手 key 還久」。這時候就需要 PaddleOCR。

PaddleOCR 是百度開源的 OCR 框架，中文辨識準確率業界公認最強。原本是 Python/C++，但社群已經把它的核心模型（檢測 + 方向分類 + 辨識三段）轉成 ONNX 格式，配合 ONNX Runtime Web 就能在瀏覽器跑。最成熟的 JS SDK 是 ppu-paddle-ocr，PP-OCRv5 全家族支援，Bun / Node / Deno / 瀏覽器都跑。

最小範例（含 WebGPU 加速）

關鍵點是第 13 行的 `executionProviders: ['webgpu', 'wasm']`——ONNX Runtime Web 會優先用 WebGPU，沒有再 fallback 到 WebAssembly。在支援 WebGPU 的瀏覽器（Chrome 113+、Edge 113+、Safari 18+）上，同一張 A4 文件的辨識時間從 WASM 的 2-3 秒砍到 WebGPU 的 0.5-1 秒。

為什麼用 INT8 量化版本

PaddleOCR 原始 FP32 模型大概 50MB，對首次載入體驗很差。INT8 量化把模型權重從 32-bit 浮點轉成 8-bit 整數，檔案大小砍到 1/4（剩 12-15MB），辨識速度在 x86 CPU 上反而快 20-50%——這是 ONNX Runtime 官方量化文件 的實測數字。準確率損失？以 PP-OCRv5 辨識模型而言，INT8 量化後英文辨識準確率從 99.22% 變 99.22%——沒有可測得的差異。

模型檔案的部署策略

PaddleOCR 三個模型檔加起來大約 25MB。三個部署選項：

• 選項一：jsDelivr CDN。把模型 push 到 GitHub repo，jsDelivr 自動 CDN 化，免費、有快取、全球 PoP。缺點是大檔案首次冷啟動可能慢一點。
• 選項二：Hugging Face Hub。Hugging Face 提供免費的模型 hosting，含 CDN。需要在 model card 寫好元資料，但對開源模型是最自然的選擇。
• 選項三：Cloudflare R2 + Cloudflare CDN。R2 的 egress 是 0 元，存大量模型也不會破產，最適合商業產品。配 Workers 還可以做版本控制與 A/B 測試。

我們自己會選第三條：Cloudflare R2 + CDN 是真正的零邊際成本，模型再多再大都不會炸帳單，而且可控性最高。檔案放上去之後，記得設定 IndexedDB 或 Service Worker 持久化快取，第一次載完就永久不再下載。

路線三：Transformers.js + TrOCR/Donut 跑文件級 OCR

如果你的場景是「不只要文字、還要結構化解析」——例如把發票直接輸出成 JSON、把名片自動填進 CRM、把履歷拆成欄位——那就需要 Transformer-based 的 OCR 模型，例如微軟的 TrOCR 或 NAVER 的 Donut。

這類模型不只做「圖片到文字」，是直接做「圖片到結構化輸出」。Donut 甚至可以跳過 OCR 那一步，直接吃整張文件圖、輸出對應的 JSON。準確率比傳統 OCR + LLM 解析的兩段式管線高，因為它把版面理解跟內容理解綁在同一個模型裡訓練。

Transformers.js 最小範例

  
  
等待上傳...

  

這段程式碼用的是 `Xenova/trocr-small-printed`，模型大小約 60MB，適合列印體英文。如果你要辨識手寫，換成 `Xenova/trocr-base-handwritten`（240MB，準確率提升但首次載入要等）。完整模型清單在 Hugging Face Transformers.js 模型列表，OCR/document understanding 相關的有 30 多個。

WebGPU 加速的實際效益

Transformers.js v3 開始原生支援 WebGPU，跟 WebAssembly fallback 比，FP16 模型在 WebGPU 上的速度通常快 3-5 倍。同一個 TrOCR-base 模型在 M2 MacBook 上的數字大概是：WASM 5-8 秒/頁、WebGPU 1.5-2.5 秒/頁。如果你的使用者主要在 2023 年後的筆電上跑，WebGPU 是值得開的開關。

真實成本拆解：到底要不要花錢

一句話結論：可以做到完全 0 元，前提是你願意接受幾個取捨。

下面這張表把所有可能的成本來源列清楚，每一項都有「最便宜方案」跟「實際企業會選的方案」對照：

關鍵洞察：純技術角度的「持續性成本」真的是 0。整個方案不需要任何雲端服務 API key、不需要伺服器 GPU、不需要按用量計費的依賴。你只付「第一次做」的開發人力——這對任何技術方案都成立，雲端 OCR API 一樣要花這筆。

什麼情況該用本地 OCR、什麼情況該乖乖用雲端 API

不是所有 OCR 場景都該往瀏覽器搬。下面這張決策表把實務上會遇到的 8 種情境分類，給你一個快速判斷的工具。

一條判斷原則：「資料能不能離開使用者裝置」這條紅線優先於「準確率高 5%」這個量級的差異。如果合規不允許上雲，就算 Tesseract.js 準確率比 Google Cloud Vision 低 10%，也只能選 Tesseract.js——你不會因為「準確率不夠」就把客戶的個資送出去。

我們在客製化系統開發中怎麼用本地 OCR

最後分享我們自己在客戶案上的應用——這部分跟教學沒有直接關係，但對你判斷「該不該找人做」有實質參考。在 AI 系統開發與 客製化系統開發 的案子裡，我們碰過幾個本地 OCR 落地場景：

第一個是 醫療產業的病歷分析系統——這個案子最初客戶想用 Google Cloud Vision 做病歷數位化，被院內法務 IT 退件兩次（HIPAA 對應的台灣個資法解讀）。我們改用 PaddleOCR + ONNX Runtime Web，所有辨識在醫護人員的工作站完成，後端只儲存結構化結果。合規會議直接過。

第二個是 AI 智慧客服系統——客戶用戶上傳收據 / 出貨單詢問訂單問題，我們把 Tesseract.js 嵌進客服介面，使用者拖一張圖進對話框、馬上抽出訂單號跟金額，後端機器人直接查單回覆。這個流程如果走雲端 API，光是每月處理 5 萬張圖的 API 費就要 USD 75，更別說使用者上傳的延遲體驗。

第三個是內部工具——我們公司自己每天就在跑 20+ 個 AI 流程，其中包含把客戶的合約 PDF、報價單掃描檔自動拆成結構化欄位的工作流。我們用 Donut + Transformers.js 跑在內部工具站，所有客戶資料從來不出公司網路。詳細的 AI 流程設計可以參考我們之前寫的 AI Agent 自己造工具——Skill Library 技能庫架構。

下一步該怎麼動

如果你看完這篇覺得「這條路適合我們公司」，可以從這三步開始：

• 第一步：列你的 OCR 場景清單。把公司目前所有「人工輸入文字進系統」的流程列出來，標出哪些文件是敏感的、哪些是公開的。敏感的就是瀏覽器端 OCR 的目標市場。
• 第二步：跑 Tesseract.js 5 分鐘 demo。複製上面那段 50 行 HTML，丟你公司的 10 張真實文件進去看準確率。如果 90% 以上 → 直接做；如果 70-90% → 試 PaddleOCR；如果不到 70% → 場景可能根本不適合瀏覽器端 OCR。
• 第三步：評估整合工程。把它接進既有系統的工程量通常是「跑通 demo」的 3-10 倍。如果你想討論這段放到自家系統的設計，可以直接找我們聊聊——我們在 客製化系統開發 跟 AI 系統開發 都做過實際的整合，初步的方向判斷大概 30 分鐘可以給你。

延伸閱讀：如果你對「為什麼企業 AI 該往本地端走」這個方向有興趣，可以接著看 NVIDIA DGX Spark 完整解析（桌上型 AI 主機）跟 Google 開源 Gemma 3 完整指南（瀏覽器/本地端跑 LLM 的開源選項）。如果你關心發票辨識怎麼從 OCR 串到後端會計流程，會計與財務部門 AI 自動化完整指南 有完整 SOP。

如果你不是工程師，正在評估企業 OCR 採購

這篇是寫給工程師、產品經理、自學者的本地端 OCR 實作教學——三方案的 zero-API-cost 部署、瀏覽器端的程式碼範例與效能比較。但如果你的身分是 IT 主管、財務長、法務長，正在評估「公司每月 10 萬份發票、病歷、合約要不要自己做 OCR」這類採購決策，這篇的技術細節對你來說太深、決策面向也太窄。我們另外寫了一篇企業採購視角的姊妹文：企業端 OCR 系統客製化開發完整指南：5 種技術路徑、3 個報價區間、5 種整合場景，從「自評需求 7 條訊號」「5 路徑選型（雲端 API / 開源自架 / fine-tune / SaaS / 混合）」「3 個報價區間（30-80 萬、100-300 萬、500 萬+）」「5 個落地場景（發票、文件數位化、病歷、進銷存、簽核）」走過一遍，幫採購方把決策想清楚再找廠商。