Why Hancom's PDF Parser Topped GitHub Trending

I’m Oswarld. Did you find your way here through my newsletter showing up on Google Discover? If you subscribe, you’ll get the fun, useful stuff as fast as possible. 🙇

Hancom’s PDF extraction tool caught developers’ attention

On March 23, Hancom announced that its PDF data extraction tool, “OpenDataLoader PDF v2.0,” had reached #1 on GitHub’s overall trending list (all languages) on March 20. According to the company, it gained over 1,800 stars in a single day on the 21st, pushing its cumulative total past 7,000. At first, I didn’t know who had built this tool. Looking at the terms of service and a Korean-language page, I wondered if it might be some Korean developer’s side project—so I was surprised to learn that Hancom, the company behind Hangul word processing software, was actually involved.

What caught my interest wasn’t just the ranking, but how the product was released. Instead of selling Hancom Office as a bundled package, the company open-sourced a standalone tool that developers could pull directly and use to extract data from documents.

To me, Hancom had always been the company behind HWP files (Hancom’s proprietary word-processor format) and the software running in public-sector offices. So seeing overseas developers encounter this company through an open-source tool for PDF processing felt genuinely new—it opened a channel for the company’s technology to reach an audience through a completely different use case than the one it’s known for domestically.

GitHub trending status and star counts are signals that attention has gathered. But they’re not proof of technical accuracy or actual enterprise adoption. Whether the developers who noticed will actually apply it to their own documents and keep using it is the next thing worth watching.

I’ll dig into what conditions produced these performance numbers, and how open-sourcing the tool this way might connect back to Hancom’s business.

Accuracy and speed have to be compared under the same settings

The benchmark the development team published evaluates reading order, tables, and heading-structure extraction across 200 PDFs. In the comparison table from the repository published on April 6, the overall scores and per-page processing times for some tools are as follows. Scores range from 0 to 1, with higher being better; processing time is faster the shorter it is.

Tool and setting	Overall score	Time per page
OpenDataLoader Hybrid	0.907	0.463s
Docling	0.882	0.762s
Nutrient	0.880	0.230s
Marker	0.861	53.932s
Unstructured hi_res	0.841	3.008s
OpenDataLoader Standard mode	0.831	0.015s

It’s worth keeping in mind that this is the development team’s own benchmark. The test documents and evaluation code are public, so anyone can verify it through the same procedure, but that doesn’t mean the same ranking holds for every kind of PDF.

One thing to disentangle here is OpenDataLoader’s two modes. 0.907 is the overall score of the hybrid mode, and 0.015 seconds is the processing time of the standard mode. The overall score of the standard mode is 0.831, and the processing time of the hybrid mode is 0.463 seconds. You shouldn’t read this as if a single setting delivered both high accuracy and the fastest speed at once.

Actual processing time varies with document composition, hardware, whether OCR is used, and the parallel-processing scheme. You can’t simply multiply this table’s per-page time by 1 million pages to pin down how long a real business workload would take. When adopting a tool, you need to measure both extraction quality and speed using the kinds of documents you actually handle. OpenDataLoader is designed to run locally even on CPU, which has the advantage of letting you test it yourself.

Pulling the content you need out of a corporate document is trickier than it sounds. PDFs are well suited to displaying a document consistently on screen, but the reading order and table structure inside may not be stored in a way that’s easy to extract. The problems are: what order to read a multi-column document in, how to connect the rows and columns of a table, and how to recognize characters in a scanned image. If you want RAG¹ to search documents and answer questions, you need to check the quality of this preprocessing.

OpenDataLoader combines rule-based direct extraction with processing that uses AI models. Ordinary pages are handled quickly, while AI capabilities can be brought to bear on complex tables or scanned documents. The hybrid feature also draws on a Docling-based tool. It’s more accurate to describe this as a design that combines existing technologies and tailors them to document processing, rather than a result of replacing every competing tool with proprietary technology.

Combining Document-Processing Experience with Outside Technology

I was curious what role Hancom’s long experience in document processing—the company behind Korea’s dominant word-processing software—actually played in this project.

Tools like Docling, Marker, and Unstructured already exist for PDF processing. Developers pick among them based on cost, accuracy, and supported formats. Scoring well on your own benchmark can be a reason to get included in that comparison set in the first place.

Where I think Hancom’s experience genuinely helps is in distinguishing document structure: knowing which line of text is a heading, how rows and columns in a table relate to each other, and in what order to read body text split across multiple columns². That said, having a long track record doesn’t by itself explain this particular score. You have to look at the actual implementation and the models used alongside it.

According to Hancom’s March announcement, the company signed a business agreement with PDF technology firm Dual Lab in July 2025 and began joint development. It released an initial version that September, and launched v2.0 on March 12 of this year. The project brought together Hancom’s document-processing experience with outside PDF-specialist technology.

There’s meaning to be found in this kind of collaboration. Hancom took what it does well and turned it into something outside developers can use, then filled the gaps by combining it with technology from other specialist firms or open source. That said, the public record of the agreement alone doesn’t tell us why Dual Lab chose Hancom in the first place.

Hancom is also pursuing integrations between its other AI products and outside technology. I read this not just as a push to sell individual products, but as an attempt to widen the points of contact so that its document-processing technology gets used inside other services as well. I think this project is a case that shows that possibility.

Can open-source users convert into paying customers?

Hancom had already tried entering overseas markets before, through products like Hancom Office Neo. Selling a finished office suite means going up against entrenched workflows, file compatibility, and familiar competing products all at once. A PDF extraction tool meets users at a different point entirely — because developers can simply bolt it onto a service they’re already building.

v2.0 switched from the existing MPL 2.0 to the Apache 2.0 license³. This license permits commercial use, modification, and redistribution, and generally doesn’t require modified code to be made public. There is a condition, though: redistributions must preserve the license and copyright notices. It’s not a license you can use with zero strings attached.

From a GTM standpoint, this is a strategy of letting developers test and adopt a feature first. If they find it useful, they can wire it into bigger workflows — and somewhere along the way, a need for paid features or support may emerge. Free usage doesn’t automatically translate into revenue, though, so which features customers will actually pay for still needs to be verified separately.

Hancom has laid out a product lineup that connects to Hancompedia, its data extraction and search service, and Hancom Assistant, which helps with task management. OpenDataLoader’s v2.0 documentation already distinguishes between free features and enterprise add-ons, and lists integration with Hancom’s commercial data-analytics features as a planned item. The company has also announced that integrations with AI tools like MCP⁴ are in the works. You could read this as a funnel: get companies to try the open-source tool first, then guide them toward evaluating the commercial product.

Whether the attention Hancom got on GitHub actually converts into real adoption is something we’ll need to watch. What will shape companies’ decisions is whether the quality and operational benefits are strong enough to justify switching from existing tools, and whether they can count on maintenance and support if something goes wrong.

Oswarld’s Lens

Watching go-to-market strategies over the years, I’ve often seen Korean companies take a finished product built for the domestic market, translate it into English, and launch it overseas. Translation is necessary, but it rarely gives new customers a reason to actually choose that product.

What caught my attention this time is that it started from a concrete problem facing developers abroad. The company gave developers who need to feed PDFs accurately into AI systems a document-extraction tool. That’s a much more direct pitch than trying to explain Hangul and Computer Office (Hancom Office), Korea’s familiar office-software suite, to people who’ve never heard of it — you can show exactly what the tool does rather than describe what it resembles.

As more AI services search external documents and call tools to do so, more developers want to directly compare document-extraction capabilities. Changing the license and open-sourcing the code and benchmarks looks like a deliberate choice to make the tool easy for these developers to test. There’s a real opportunity for it to become a widely used tool, but it’s too early to call it a market standard.

Other Korean companies could consider a similar approach. The idea would be to look across capabilities built up in search, messaging, financial-service UX, or logistics operations, and ask whether any of them solve a real problem for outside customers. Not every piece of technology can be unbundled and sold, though. Companies need to check whether it actually works outside their own context, and whether they can absorb the cost of supporting and operating it externally.

There’s something for individuals to think about here too. Spend enough time in one field and you develop judgment that generic explanations can’t capture — knowledge about which errors tend to recur, or which conditions call for a different approach. I think organizing that kind of experience so others can actually use it is becoming increasingly important.

Simply having a lot of experience isn’t enough to get that experience recognized as valuable. You have to explain it through cases and criteria, or turn it into a tool that actually works, before anyone else can judge whether it’s useful.

Closing

What I want to take away from Hancom’s latest move is how it broke down a familiar product to fit a different customer’s problem. Also worth noting: it opened the results up so developers could try them out and compare for themselves.

It’s worth thinking about which parts of the work you’ve done for a long time could spare someone else the same trial and error. If you turn that standard into an explanation or a tool and let someone actually use it, you’ll get a much more concrete sense of how useful it really is. I’ll be watching to see how much staying power — and what kind of business results — Hancom’s attempt here ends up generating.

References & Further Reading

Primary sources

• OpenDataLoader benchmark, saved 2026.04.06. The source for the per-mode scores and processing times cited in this piece. The current benchmark repository has the test data and evaluation code.
• Hancom, announcement of OpenDataLoader PDF v2.0 reaching #1 on GitHub Trending, 2026.03.23. The company’s own statement on the ranking, star count, co-development, and release timeline at the time.
• OpenDataLoader v2.0.0 README. Details on the standard/hybrid modes, free-vs-enterprise features, and the roadmap as of that release.
• Apache License 2.0. Spells out what use, modification, and redistribution are permitted, and under what notice requirements.

Background

• “Best PDF Parsers for AI and RAG Workflows in 2026”, Firecrawl Blog. Compares the strengths and limits of competing tools like Docling, Marker, and Unstructured — useful for gauging where OpenDataLoader sits in the market.
• Auer et al., “Docling Technical Report”, arXiv:2408.09869, 2024. The official writeup of Docling’s design philosophy; reading it alongside OpenDataLoader highlights how differently the two tools approach the problem.
• Hancom’s OpenDataLoader GitHub repository. The official repo if you want to try it yourself — the benchmark section of the README also has comparison figures against other tools.

The author is Oswarld (Kwangseob Ahn). Current roles: Adjunct Professor at Sejong University, Strategy Consultant at INLEVEL9. Career, research, books, and recent work are kept current on the About page. Latest · July 2026: HEMA-2: A Consolidation-Aware Tri-Memory Architecture with Multi-Channel Scheduling for Lifelong Conversational AI.

Footnotes

1. RAG (Retrieval-Augmented Generation): a method where AI retrieves external material relevant to a question and uses it as reference when answering. Not just extraction quality, but retrieval, document chunking, and answer generation all affect the outcome. ↩

2. Document structure knowledge: knowledge used to distinguish a document’s components — headings, body text, tables — along with their relationships and reading order. ↩

3. Apache License 2.0: an open-source license that permits commercial use, modification, and redistribution, subject to conditions like preserving license/copyright notices and marking changes. ↩

4. MCP (Model Context Protocol): an open protocol AI applications use to connect to external tools and data. ↩