bible, structured scripture text in JSON and XML across 85 languages

What the project is and how it was produced

thiagobodruk/bible publishes Bible text as JSON and XML, with 141 versions across 85 languages, described as clean, structured data for Bible apps, verse search and NLP and AI datasets.

The stated purpose is practical rather than scholarly. The README asks whether you want to build a Bible based app or an API for verse search, and says the main objective is to allow people to create those things using sources in their own language. That framing explains the coverage: the languages include Afrikaans, Akan, Albanian, Armenian, Basque, Belarusian, Bislama, Bulgarian, Burmese, Catalan, Cebuano, Central Kurdish, Chinese, Croatian, Czech and Dutch alongside the usual English, Portuguese and Spanish set.

The provenance is stated plainly, and it matters for anyone planning to rely on the text. The source files were generated using a Python based crawler, and the README says these files may contain minor issues related to encoding and syntax. That is an unusual thing for a dataset README to say, and it tells you the text was collected from public web sources rather than transcribed from a published edition, so a small number of verses will be imperfect.

The repository layout is the dataset itself. There are json/ and xml/ directories at the top level, a .github directory, a LICENSE, an assets directory with the donation button image, and seven README translations covering Portuguese from Brazil, Spanish, French, Italian, German, Japanese and Simplified Chinese. There is no code, no build system and no scripts directory, which is worth noting: this is data, not a library, and the deliverable is the files.

The releases are numbered simply, v2.3 on the same day as the last push on 2026-10-19, v2.2 on 2026-10-16 and v2.1 on 2026-09-24. The licence is MIT, and the README describes the text as permissively sourced.

How the files are named and organised

Each version gets a directory named with a language code and a short version code, and the README's table is the index. The English entries show the pattern clearly: en_asv for the American Standard Version 1901, en_amp for the Amplified Bible, en_bbe for Basic English, en_bsb for the Berean Standard Bible, en_csb for the Christian Standard Bible, en_cev for the Contemporary English Version, en_darby for Darby's Translation 1890, en_dra for the Douay-Rheims American 1899, en_esv for the English Standard Version, en_fbv for the Free Bible Version, en_gnv for the Geneva Bible, en_gnt for the Good News Translation, en_jub for the Jubilee Bible, en_kjv for the King James Version, en_kjva for the King James Version with Apocrypha, and further entries including the Lexham English Bible.

The Brazilian Portuguese list is a good illustration of why this dataset is useful. It carries pt_aa Almeida Revisada Imprensa Bíblica, pt_acf Almeida Corrigida e Revisada Fiel, pt_ara Almeida Revista e Atualizada, pt_arc Almeida Revista e Corrigida, pt_rc69 Almeida Revista e Corrigida 1969, pt_a21 Almeida Século 21, pt_bpt09 Bíblia para Todos, pt_avm Bíblia Sagrada Ave-Maria, pt_vfl Bíblia Sagrada Versão Fácil de Ler, pt_pastoral Edição Pastoral, pt_kja and pt_bkj the King James updates, pt_naa Nova Almeida Atualizada, pt_nbv Nova Bíblia Viva 2007, pt_ntlh Nova Tradução na Linguagem de Hoje, pt_nvi and pt_nvi2011 Nova Versão Internacional, pt_nvt Nova Versão Transformadora, pt_ol O Livro, pt_tb Tradução Brasileira and pt_matos. That is twenty versions of one language, and none of them is the same text.

The language index is also published as a file. The README carries a badge that counts the length of json/index.json, which means there is a machine-readable list of the available languages rather than only a table to scrape.

The notes column in the table is where the caveats live, and they are worth reading before you align datasets. Several editions have Malachi with three chapters instead of four, which is a numbering difference that will silently misalign verse references. The Ancient Greek Septuagint in the Brenton translation covers 36 books of the Greek scriptures and Proverbs 30 empty in that edition's numbering. The New Etchmiadzin Armenian Bible is incomplete with 64 of 66 books, Esther and Daniel missing. The Dutch Canisiusvertaling 1939 is likewise 64 of 66 books. Croatian Knjiga o Kristu covers 27 books. The Textus Receptus Greek likewise covers 27 books.

For a search index, that last category is a feature. A dataset covering only 27 books in the original language is exactly what a cross-lingual alignment experiment needs.

Why the alignment matters for retrieval and training

The README's section on being ready for AI and large language models is the strongest argument for the project, and it rests on a specific technical property.

Every language and version uses the same canonical book abbreviations, so verses align out of the box for embeddings, retrieval-augmented generation pipelines, fine-tuning and cross-lingual alignment tasks. That is the whole value proposition.

Consider what happens without it. If one dataset uses Genesis 1:1 and another uses Gen 1:1 and a third uses 1:1, every alignment task needs a mapping table, and a mapping table is a source of silent errors that get discovered during evaluation rather than before. With a shared scheme, a verse identifier means the same thing in every file, and the alignment work disappears.

The other property named is cleanliness: per-verse structured JSON and XML with no HTML, no markup noise and no scraping artifacts. That matters more than it sounds. A corpus built by crawling web pages usually carries footnotes, verse numbers, superscript letters, cross-reference markers and stray markup inside the text field. Stripping those out is work that a downstream user otherwise does with a pile of regular expressions, and does badly.

The description of the output being clean, per-verse structured data also suggests the files are verse-addressable rather than chapter blobs, which is the granularity a retrieval system wants.

The practical uses this serves are the obvious ones: scripture apps with their own search, chat products that quote verses accurately, and training data for models that need religious text in many languages. The dataset does not come with an API, so the reader has to load the files directly, but for a static dataset that is the right shape, since the data never changes and can be vendored.

Working with the files in a project

There is no installer and no client library, because the deliverable is the data itself. The json/ and xml/ directories are meant to be cloned or downloaded and then read directly.

The workflow is straightforward. Clone the repository, pick the language and version directories you need, and read the files from disk. For a search application, the per-verse structure means you can index one file per version without preprocessing, and the shared book abbreviations mean your query parser only has to understand one naming scheme.

Two details make that workable. The language list is available as json/index.json, which the README's own badge reads to count the available languages, so a program can discover what exists rather than hard-coding a list. And because the text is MIT licensed with permissively-sourced content, you can bundle it into an application or a model dataset without attribution obligations beyond the licence itself.

The versioning tells you when to check back. Releases v2.1, v2.2 and v2.3 landed within a month of each other in late 2026, so the collection is being extended rather than frozen. If you pin to a release, you get a stable set of directories, and if you follow master you get new versions as they appear.

For a scripture application, the sensible first step is to load one language, one well-known version such as en_kjv or en_esv, and build the search index before touching the other 140. Once the schema and the chapter-count caveats are handled for one file, the same code handles the rest, and the cross-lingual alignment you get for free is the part that makes the collection worth having rather than downloading a single translation file from somewhere else.

Limitations and how it compares with the alternatives

The main limitation is provenance. Because the text was produced by a crawler over public sources, the files may contain encoding and syntax issues, and there is no critical apparatus, no apparatus of textual criticism and no record of which printed edition each file was transcribed from beyond the table's version name. For a devotional app or a search index that is irrelevant. For a project quoting scripture in a legal or academic context, it is disqualifying, because there is nothing to cite.

The second limitation is the edition unevenness the table documents so carefully. Chapter counts differ between editions for Malachi in many languages, several translations are partial, and the numbering inside an individual book can differ. Any pipeline that assumes a fixed schema across all 141 versions will break, and the table is the only documentation of where.

The third is that there is no tooling. You get JSON and XML files and a wiki, but no client library, no search index, no validation script and no update mechanism beyond watching the releases. For a static dataset that is manageable, since you can load it once and cache it, but it does mean the chapter-count and partial-book questions are yours to handle.

The alternative worth naming is the existing scripture APIs and datasets. Several Bible APIs exist commercially and some open projects distribute translations as separate repositories, often one per version. The difference in approach is scope and consistency. A set of per-version repositories gives you cleaner provenance for one translation, but you have to assemble the collection yourself and you have no cross-language alignment. A consolidated dataset with a shared book scheme gives you alignment out of the box at the cost of provenance and the caveats above.

For a language modelling exercise, the aligned structure is worth more than edition fidelity. For a publishing project, it is the other way round.

Editorial conclusion

Adopt this dataset if you are building a scripture application, a multilingual search index or a language modelling corpus and you want per-verse structured text without scraping markup out of web pages. Skip it if you need a specific critical edition with an established scholarly apparatus, since the text comes from public web sources rather than a published edition. Verify first by loading one language directory from json/ and checking the verse numbering against a version you already trust, because the table records chapter-count differences in several editions and Malachi appears with three chapters in many of them.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. thiagobodruk/bible on GitHub