[HN Gopher] Show HN: Ocrbase - pdf - .md/.json document OCR and ...
___________________________________________________________________
Show HN: Ocrbase - pdf - .md/.json document OCR and structured
extraction API
Author : adammajcher
Score : 81 points
Date : 2026-01-20 13:10 UTC (9 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| mechazawa wrote:
| Is only bun supported or also regular node?
| adammajcher wrote:
| it's bun first because of performance
| hersko wrote:
| I have a flow where i extract text from a pdf with pdf-parse and
| then feed that to an ai for data extraction. If that fails i
| convert it to a png and send the image for data extraction. This
| works very well and would presumably be far cheaper as i'm
| generally sending text to the model instead of relying on images.
| Isn't just sending the images for ocr significantly more
| expensive?
| mimim1mi wrote:
| By definition, OCR means optical character recognition. It
| depends on the contents of the PDF what kind of extraction
| methodology can work. Often some available PDFs are just scans
| of printed documents or handwritten notes. If machine readable
| text is available your approach is great.
| trollbridge wrote:
| I always render an image and OCR that so I don't get odd
| problems from invisible text and it also avoids being affected
| by anything for SEO.
| saaaaaam wrote:
| There was an interesting discussion on here a couple of months
| back about images vs text, driven by this article:
| https://www.seangoedecke.com/text-tokens-as-image-tokens/
|
| Discussion is here:
| https://news.ycombinator.com/item?id=45652952
| unrahul wrote:
| I have seen this flow in what people in some startups call
| "Agentic OCR", its essentially a control flow that is coded
| that tries pdf-parse first or a similar non expensive approach,
| and if it fails a threshold then use screenshot to text
| extraction.
| sgc wrote:
| How does this compare to dots.ocr? I got fantastic results when I
| tested dots.
|
| https://github.com/rednote-hilab/dots.ocr
| mjrpes wrote:
| Ocrbase is CUDA only while dots.ocr uses vLLM, so should
| support ROCm/AMD cards?
| actionfromafar wrote:
| How about CPU?
| v3ss0n wrote:
| How this is better over Surya/Marker or kreuzberg
| https://github.com/kreuzberg-dev/kreuzberg.
| jadbox wrote:
| Sounds like someone needs to run their own test cases and
| report back on which solution does a better job...
| kspacewalk2 wrote:
| Let me fire up Claude code.
| sixtyj wrote:
| Let me fire up Tesseract.
|
| https://github.com/tesseract-ocr
| Jimmc414 wrote:
| I fought with Tesseract for quite a while. Its good if
| high accuracy doesn't matter. Transcribing a book from
| clean, consistent non-skewed data its fine and an LLM
| might even be able to clean it up. But for legal or
| accounting data from hand scanned documents, the error
| rate made it untenable. Even clean, scanned documents of
| the same category have all sorts of density and skew
| anomalies that get misinterpreted. You'll pull your hair
| out trying to account for edge cases and never get the
| results you need even with numerous adjustments and model
| retraining on errors.
|
| Flash 2.5 or 3 with thinking gave the best results.
| sixtyj wrote:
| Thanks. I was surprised that Tesseract had recognized
| poorly scanned magazines and with some Python library I
| was able to transcribe two-columns layout with almost no
| errors.
|
| Tesseract is a cheap solution as it doesn't touch any
| LLM.
|
| For invoices, Gemini flash is really good, for sure, and
| you receive "sorted" data as well. So definitely thumbs
| up. I use it for transcription of difficult magazine
| layout.
|
| I think that for such legally problematic usage as
| companies don't like to share financial data with Google,
| it is be better to use a local model.
|
| Ollama or HuggingFace has a lot of them.
| sync wrote:
| This is essentially a (vibe-coded?) wrapper around PaddleOCR:
| https://github.com/PaddlePaddle/PaddleOCR
|
| The "guts" are here:
| https://github.com/majcheradam/ocrbase/blob/7706ef79493c47e8...
| Oras wrote:
| Claude is included in the contributors, so the OP didn't hide
| it
| Tiberium wrote:
| At this point it feels like HN is becoming more like Reddit,
| most people upvote before actually checking the repo.
| M4R5H4LL wrote:
| Most production software is wrappers around existing libraries.
| The relevant question is whether this wrapper adds operational
| or usability value, not whether it reimplements OCR. If there
| are architectural or reliability concerns, it'd be more useful
| to call those out directly.
| tuwtuwtuwtuw wrote:
| Sure. The self host guide tells me to enter my github secret,
| in plain-text, in an env file. But it doesn't tell me why I
| should do that.
|
| Do people actually store their secrets in plain text on the
| file system in production environments? Just seems a bit wild
| to me.
| adammajcher wrote:
| well, you can use secrets manager as well
| constantinum wrote:
| What matters most is how well OCR and structured data extraction
| tools handle documents with high variation at production scale.
| In real workflows like accounting, every invoice, purchase order,
| or contract can look different. The extraction system must still
| work reliably across these variations with minimal ongoing
| tweaks.
|
| Equally important is how easily you can build a human-in-the-loop
| review layer on top of the tool. This is needed not only to
| improve accuracy, but also for compliance--especially in
| regulated industries like insurance.
|
| Other tools in this space:
|
| LLMWhisperer/Unstract(AGPL)
|
| Reducto
|
| Extend Ai
|
| LLamaparse
|
| Docling
| cess11 wrote:
| Why is 12GB+ VRAM a requirement? The OCR model looks kind of
| small, https://huggingface.co/PaddlePaddle/PaddleOCR-
| VL/tree/main, so I'm assuming it is some processing afterwards it
| would be used for.
| adammajcher wrote:
| fixed
| cess11 wrote:
| OK, thanks, so it runs on a couple GB of CUDA?
| binalpatel wrote:
| This is admittedly dated but even back in December 2023 GPT-4
| with it's Vision preview was able to very reliably do structured
| extraction, and I'd imagine Gemini 3 Flash is much better than
| back then.
|
| https://binal.pub/2023/12/structured-ocr-with-gpt-vision/
|
| Back of the napkin math (which I could be messing up completely)
| but I think you could process a 100 page PDF for ~$0.50 or less
| using Gemini 3 Flash?
|
| >560 input tokens per page * 100 pages = 56000 tokens = $0.028
| input ($0.5/m input tokens) >~1000 output tokens per page * 100
| pages = $0.30 output ($3/m output tokens)
|
| (https://ai.google.dev/gemini-api/docs/gemini-3#media_resolut...)
| adammajcher wrote:
| sure, in some small projects I recommend my friends to use
| gemini 3 flash. ocrbase is aimed more at scale and self-
| hosting: fixed infra cost, high throughput, and no data leaving
| your environment. at large volumes, that tradeoff starts to
| matter more than per-100-page pricing
| fmirkowski wrote:
| having worked with paddleocr, tesseract and many other ocr tools
| before this is still one of the best and smoothest ocr
| experiences ive ever had, deployed in minutes
___________________________________________________________________
(page generated 2026-01-20 23:01 UTC)