AI & TechIssue #90 ·

Hancom's PDF Tool Hits #1 on GitHub Trending

35 years of document know-how just got cashed into global currency for the first time.

Hancom's PDF Tool Hits #1 on GitHub Trending

Hi, this is Oswarld. Did you land here after spotting my newsletter on Google Discover? If you subscribe, you’ll get fun, useful newsletters as fast as possible. 🙇

Opening

Hello, subscriber. On March 20th, a PDF data-extraction tool called “OpenDataLoader PDF v2.0” hit the #1 spot on GitHub’s overall trending chart. On the 21st alone, its star count jumped by 1,800, pushing the total past 7,000. At first, I had no idea who’d built it. Then I noticed a terms-of-service page and a Korean-language page and thought, is this a Korean developer? I was floored when I found out it was made by Hangul and Computer. Yes, that’s right — that Hancom.

I could just let this one-line piece of news slide by — “guess a Korean company built a decent open-source project.” But I see this as a meaningful inflection point for Korea’s IT industry.

Because Hancom has long been cited as the poster child of Korea’s IT “Galápagos” — the HWP file format, heavy dependence on government and public-sector contracts, negligible overseas revenue. Hancom Office has, for over 30 years, effectively sold only within Korea. While Microsoft Office held over 95% of the global office-suite market, Hancom’s entire game plan was defending roughly 30% market share domestically.

This is the first time Hancom’s technology has been directly validated by the global developer community — with no allowance made for being “a Korean company,” just raw benchmark numbers and star counts. Reaching #1 trending among roughly 400 million projects registered on GitHub is close to threading a needle.

Today, I’ll unpack how this was possible, and what this pattern means for other Korean companies — and for us as individuals.

📊 What the Benchmarks Say

Let’s start with the numbers. In OpenDataLoader’s own published benchmark, the average per-document scores for reading-order, table, and title extraction were as follows.

  • OpenDataLoader (hybrid): 0.907 ← #1
  • Docling: 0.882
  • Nutrient: 0.880
  • Marker: 0.861
  • Unstructured (hi_res): 0.841

I should be honest that this is a self-reported benchmark. That said, Hancom has published both the test data and the reproduction code on GitHub, so anyone who wants to verify the results can run it themselves.

What’s actually shocking here isn’t the score itself — it’s the speed. OpenDataLoader processes a page in 0.015 seconds. Marker, which shows similar accuracy, takes about 53.9 seconds per page. That’s roughly a 1,000x difference, and Marker requires a GPU, while OpenDataLoader runs on CPU alone.

Why does this matter? Say a company needs to process 1 million pages of PDFs — a task that would take Marker about 624 days, OpenDataLoader finishes in roughly 4 hours. For anyone building an AI training-data pipeline, this isn’t “a bit faster” — it’s a job that becomes possible for the first time. It opens the door to small businesses and solo developers who don’t have access to high-end GPU infrastructure.

It’s often said that 80–90% of a company’s operational data exists in unstructured formats like PDFs and documents, and feeding that data to AI has always been bottlenecked at the cleaning stage. PDF is a format optimized for rendering nicely on screen, not for extracting data. Where does a table start and end? In what order should a multi-column layout be read? How do you pull text embedded inside images? A tool that solves these problems accurately and fast is core infrastructure for the RAG1 era.

The secret is its “hybrid engine.” Simple text is processed instantly via rule-based logic, and AI is only invoked for complex tables or multi-column layouts. That’s a different design from other tools that run a heavy AI model on every single page.