[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"$f1xn9ji355v72h":3},{"code":4,"message":5,"data":6,"timestamp":57},10000,"success",{"full_name":7,"position":8,"description":9,"language":10,"stars":11,"forks":12,"stars_gained":13,"age_days":14,"hn_threads":15,"one_liner":22,"summary_md":23,"topic":24,"github_topics":27,"license":48,"homepage":49,"updated_at":50,"history":51},"opendataloader-project\u002Fopendataloader-pdf",2,"PDF Parser for AI-ready data. Automate PDF accessibility. Open-source.","Java",29991,2859,11,529,[16],{"id":17,"title":18,"points":19,"comments":20,"posted_at":21},45347147,"OpenDataLoader-PDF: An open source tool for structured PDF parsing",109,28,"2025-09-23","Extracts structured Markdown, JSON with bounding boxes, and tagged PDF from PDFs, for RAG pipelines and accessibility remediation.","Worth a look if your pipeline chokes on PDFs: this is a deterministic local parser that also exposes a hybrid mode for the pages that defeat heuristics. Two caveats: the AI-heavy capabilities need an extra backend install, and accessibility splits into a free auto-tagging core and a paid PDF\u002FUA export.\n\n## The problem\nYou have a folder of PDFs — reports, papers, bank statements, scanned forms — and you want clean text, tables and reading order for a RAG index. Copy-paste mangles columns, naive extractors scramble multi-column layouts, and every bad page becomes a manual fix. With this tool you point `convert()` at files or a directory and get Markdown, JSON or HTML out, with element coordinates and heading\u002Flist\u002Ftable structure reconstructed. For accessibility, an untagged PDF that a screen reader reads in document order becomes a Tagged PDF with a structure tree that remediation work can build on.\n\n## What's different\nThe mechanism is local layout analysis built on XY-Cut++ reading-order logic, producing deterministic output with bounding boxes for every element, plus optional respect for an existing PDF structure tree. Determinism matters in a data pipeline: the same input gives the same output, so diffs and regression tests are meaningful. When heuristics aren't enough — complex borderless tables, scanned pages needing OCR, formulas, chart descriptions — hybrid mode routes those pages to an AI backend, installed via the `[hybrid]` extra. The trade-off is the usual one: local mode is fast and predictable but struggles with exactly the hard pages; hybrid mode improves those pages at the cost of a second service, an install step, and less deterministic output.\n\nTagged PDF handling is a distinct behavior: when tags exist and you enable `use_struct_tree`, the parser takes the author's structure instead of guessing. The README says this backfires on poorly tagged files and that `use_struct_tree` overrides hybrid. On accessibility, the free tier stops at auto-tagging to Tagged PDF; PDF\u002FUA export and the accessibility studio are enterprise add-ons.\n\n## Who should try it\nGood fit: an engineer building document ingestion who can accept a Java dependency and wants coordinate-bearing JSON with Python\u002FNode wrappers, or an accessibility team needing a first-pass structure tree on untagged PDFs. Poor fit: someone who only needs simple text dumps, or a project requiring an in-process C++ library — one Hacker News commenter asked for C++-callable table extraction and found the Java\u002FPython stack a blocker. If you need PDF\u002FUA output entirely under a permissive license, look elsewhere too.\n\nA firsthand report: on 2025-09-23 a commenter [said extracted JSON from bank statements](https:\u002F\u002Fnews.ycombinator.com\u002Fitem?id=45347147) looked usable in one shot compared with other tools tried, while noting it needed deeper checking. One document type and version, not a benchmark.\n\n## Requirements and limitations\nJava 11+ and Python 3.10+ for the pip path; Node.js and Java quick-start paths also exist. Because each `convert()` spawns a JVM, the README warns repeated single-file calls are slow — batch inputs in one call. Hybrid, OCR, formula and chart features require the extra install and a running backend; OCR quality varies by engine and language.\n\nThe README's benchmark numbers (0.907 overall, 0.928 table accuracy, 0.015s\u002Fpage local) are the project's own and unverified here; treat them as a hypothesis for your documents. License moved from MPL 2.0 to Apache 2.0 at version 2.0, with pre-2.0 versions staying under MPL. Read the [tagged-PDF guidance](https:\u002F\u002Fopendataloader.org\u002Fdocs\u002Ftagged-pdf) before relying on structure tags.\n\n## HotRepo's take\nHotRepo recorded 29,983 stars on 2026-10-24 and 29,988 on 2026-10-25, appearing on the daily board on 2 days across that two-day sample. That's a snapshot, not a trend: persistence can't be judged from two dated observations. Verify first whether `use_struct_tree` or hybrid gives better output on your actual tagged-PDF corpus.",{"slug":25,"name":26},"data","Data",[28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47],"a11y","accessibility","ai","bounding-box","document-parsing","eaa","html","json","markdown","ocr","ocr-recognition","pdf","pdf-accessibility","pdf-converter","pdf-extraction","pdf-parser","pdf-ua","rag","tables","tagged-pdf","Apache-2.0","https:\u002F\u002Fopendataloader.org","2026-10-25T03:26:44Z",[52,55],{"date":53,"stars":54,"stars_gained":13},"2026-10-24",29983,{"date":56,"stars":11,"stars_gained":13},"2026-10-25",1792906250]