quran-api serves 440 translations as static JSON on a CDN, with no server to run

The API is a Git repository on a CDN, not a running service

quran-api is a repository of Quran translations structured in REST architectural style, and the whole delivery mechanism is that structure. The URL pattern is:

`https://cdn.jsdelivr.net/gh/fawazahmed0/quran-api@{apiVersion}/{endpoint}`

Every endpoint is a file in the repository, and jsDelivr serves them. There is no application server, no database query, no API key and no account. The version segment, currently @1, is the API version, and it doubles as a git branch, so a different version is a different ref.

The stated features are free and blazing fast response, no rate limits, and 90+ languages with 440+ translations including Latin or roman script versions. The languages section later gives the exact figure, 98 different languages, and points to a Translations.md list plus the editions.json collection.

The licence is the Unlicense, which is the public domain dedication and one of the most permissive licences in practice, so the data can be embedded, redistributed and monetised without attribution obligations. The last push was on 2026-09-12, and the repository has no GitHub releases, so the version history is the git history of the branch.

The stated purpose is to spread the word of God everywhere in the world, and the repository also carries a religious framing: it opens with the phrase In the name of God, who has guided me to do this work. The practical result is a dataset rather than a product, which is what makes it usable in a way that a hosted service with quotas often is not.

The endpoint tree follows the structure of the text itself

The endpoints are the interesting design decision, because they let you fetch exactly the granularity you need without the server doing any filtering for you.

/editions lists all available editions in prettified JSON, and the same path gives a minified version. /editions/{editionName} returns the whole Quran or translation. /editions/{editionName}/{ChapterNo} returns one chapter, and /editions/{editionName}/{ChapterNo}/{VerseNo} returns a single verse, with the documented example being chapter 5 verse 10.

The same edition can be requested in different scripts by suffixing the edition name. Adding -la gives the latin or roman script version, and adding -lad gives a latin script with diacritical marks. The documented example uses ben-muhiuddinkhan, and the romanised variant ben-muhiuddinkhan-la.

Beyond chapters and verses there are the traditional divisions. /editions/{editionName}/juzs/{juzNo} gets a juz, and the README lists the parallel paths for rukus/{rukuNo}, pages/{pageNo}, manzils/{manzilNo} and maqras/{maqraNo}. Two more global endpoints exist: /info returns details such as the number of juzs, sajdas and rukus in the Quran, and /fonts lists the available Arabic fonts.

Because the divisions are just paths, a client can traverse the text in whichever unit its use case calls for, whether that is a page for a scroll view, a juz for a study plan, or a single ayah for a share card.

Two formats per endpoint, and the fallback the README insists on

Every endpoint returns the data in two formats, .json and .min.json, and the endpoints support the HTTP GET method. The minified variants are smaller, which matters when you are shipping a whole edition to a browser, and the prettified ones are easier to read while debugging.

The important operational detail is that the two formats work as a fallback for each other. If the .min.json link fails you can use the .json link and vice versa.

The README turns that into a requirement rather than a suggestion, with a warning that you should include a fallback mechanism in your code, and it links to an issue for the details. That warning is the single most practical piece of advice in the document. A CDN-backed static file can fail for reasons that have nothing to do with your code, a transient edge problem, a cache miss, a network hiccup on a mobile connection, and an application that hardcodes one URL and shows an error page will be visibly broken in a way that an application with a two-line fallback will not be.

This is the cost of the static-file approach. You get no SLA, no uptime guarantee and no support channel, so the resilience has to live in the client.

Font coverage is the failure mode you will actually hit

Displaying the text correctly takes more than fetching the JSON, and the README spends real space on it. The fonts endpoint lists the Arabic fonts available, and the guidance is to use those to display the Quran text. If the font shows a few tofu characters, meaning the rectangles you get when a font lacks a glyph, then you should use fonts with the -full suffix, which has complete Arabic Unicode support. There is a separate fontfull.md document for the details.

The same problem applies on the translation side and for a different reason. By default the operating system does not have a font installed for every language, so you will have to add fonts for a few languages such as Burmese to show the translation properly, and Google Noto Fonts is the recommended source. The README notes that otherwise you will end up with tofu characters.

This is a genuine trap in a multi-language scripture app. The data layer looks solved once the JSON is fetched, and the actual bug reports come from a user on a device without a font for the language they selected. The -full font suffix and an explicit font fallback chain in your stylesheet are the difference between readable text and a grid of boxes.

It is also worth noting the caveat the README attaches to the content itself. A few of the translations were OCRed and may contain mistakes, and the project asks for mistakes to be reported through the issue tracker rather than fixed quietly in a client.

The repository is also the toolchain that produces the data

What is unusual about this project is that the data and the pipeline to produce it live in the same repository, and the top-level listing shows it: a database/ directory, scripts/, a start/ directory, translate.py, apiscript.js, Preprocessing.md, download.md, dev.md, References.md, Translations.md and CONTRIBUTING-LOCAL.md alongside the published editions/ directory, editions.json, fonts/ and fonts.json, info.json and isocodes/.

The npm package.json is the automation side and it is tiny. The main entry is apiscript.js and the dependencies are extract-zip 2.0.1, playwright at latest, and opentype.js 1.3.4. Playwright and opentype.js together explain the shape of the work: a headless browser to extract text from source documents, and font parsing to work out which fonts cover which characters, which is what produces the fonts index and the -full suffix coverage list.

The Python side is a single requirement, googletrans 3.0.0, which is what the translate.py script uses for the translation and transliteration passes. The isocodes/ directory holds the language code mapping, and the documentation files describe the preprocessing steps and the download process for new editions.

The contribution guidance reflects this. The README asks contributors to add new translations to the repository rather than fixing things locally in their own project, and CONTRIBUTING.md and CONTRIBUTING-LOCAL.md split the work between upstream contributions and local setup. The result is that a user who finds a translation error is expected to become a contributor, which is also the mechanism by which the 440 editions got there.

What this data source is not

The honest limitation is the difference between a large dataset and a vetted one. The collection is built from many sources, and the README itself flags that some translations were produced by OCR and may contain mistakes. There is no statement in the documentation about scholarly review, editorial process or version pinning of a specific edition's content, and the editions index is a flat list of names without a quality rating.

That matters differently depending on what you are building. For a reading app, a search tool or a bot that surfaces text for study, a broad catalogue with a reported-errors channel is a workable tradeoff, because the reader can see the translation name. For an application making claims about meaning, quoting scripture in a product, or anything where a mistranslation has consequences, the edition needs to be chosen and checked by someone qualified rather than picked from a list of 440.

The second limitation is the delivery contract. There is no uptime guarantee, no version negotiation beyond the git ref in the path, and no deprecation policy for edition names. The .min.json and .json fallback is the mitigation the project offers, and it is a mitigation against transient failure, not against a content change.

The third is scale of adoption work. There is no client library here, no SDK for any language, and no auth. You write the fetch, the caching, the retry and the font handling yourself. For a small app that is a weekend. For a large product, the total integration work is more than picking a hosted service would be, and the trade you are making is dependency on a third-party CDN in exchange for zero cost and zero rate limit.

Editorial conclusion

quran-api fits a developer building a scripture app, a bot or a study tool who wants free, fast, keyless access to Quran text in many languages, and it does not fit a project that needs a vetted scholarly edition or a guarantee that a specific translation is error free. Before shipping, pick your edition from the editions index and read the font guidance, since Arabic text needs a font with full Unicode coverage and translations need fonts for their own script, and implement the fallback between the .json and .min.json URLs that the README explicitly warns about.

Frequently asked questions

Official sources

1. fawazahmed0/quran-api on GitHub
2. Issues
3. License: Unlicense
4. README