StarRailRes and the JSON index behind a Honkai: Star Rail resource site

What the repository holds

StarRailRes is a repository of Honkai: Star Rail game resources. The site it serves is at march7th.xyz, and the data it publishes comes from another project, Dimbreath/StarRailData, which the README names as the game data source.

That division is the first thing to understand. StarRailRes is not where the data is extracted; it is where the extracted data is published in a form a website can consume, alongside the image assets the site needs. The README also points at a font directory in the repository tree, which is presumably the typeface used by the site.

The top-level entries make the shape clear: icon/, image/, guide/, index_new/, index_min/, plus info.json and a LICENSE. The three asset directories are the visual side, and the two index directories are the data side.

The licence is AGPL-3.0, and the repository is not archived with the last push on 2026-09-29. There are no GitHub releases, which is consistent with a repository whose version is the game version rather than a software release.

The audience is anyone building on Star Rail community data: a fan wiki, a database-driven companion site, a character planning tool. For those users the value is in the structure: the data is already split into per-category JSON files per language, so a site can fetch exactly the slice it needs instead of downloading a monolithic dump.

The index_new tree, and what each file holds

The index_new directory is organised by language, and each language folder holds one JSON file per data category. The structure is:

StarRailRes
└─ index_new
   └─ [language]

The files inside a language folder cover the whole game surface. The comment next to each filename in the original documentation gives the category, and the set divides into three groups.

The first group is the game's static taxonomies: paths, elements and properties, which are the character path, the element and the property.

The second group is characters, and it is the largest. There is a characters.json for basic information, character_ranks.json for the character rank, character_skills.json for skills, character_skill_trees.json for the skill tree, and character_promotions.json for promotion and level.

The third group is equipment and materials. light_cones.json holds the light cone basic information, with light_cone_ranks.json and light_cone_promotions.json alongside it for ranks and promotion. relics.json, relic_sets.json, relic_main_affixs.json and relic_sub_affixs.json cover relics, sets and the main and sub affix groups. And items.json is the material list.

The naming is worth pausing on for anyone who will build a parser around it. The files are plural in name and singular in concept in a slightly inconsistent way, with characters.json and light_cones.json in the same directory, and the affix files use main_affixs and sub_affixs rather than affixes. None of that is a problem for a consumer that reads the files it needs, but it is a hint that the layout is descriptive of the game data rather than designed as a published API.

The per-language split is the other structural decision. A site that serves English does not need to fetch nine other language trees, and a Japanese site does not need the English character data, which is the kind of granularity that matters once the file set grows.

index_min, and why there are two copies

Alongside index_new there is index_min, described as the compressed index files directory, and the README's structure diagram lists them side by side:

The published tree lists the icon, image and guide asset directories alongside the two index directories, index_new and index_min.

So the same index content is published twice, once in full and once compressed, and the two directories have different uses. The full tree is what you read and diff during development or when you are building a local copy; the compressed tree is what a site serves to a browser over the network.

This is a deliberate choice about the delivery boundary. A JSON index for the full character and light cone catalogue is not small, and if the server serves the same content to every visitor, the transfer cost is paid on every request. A compressed variant lets a site serve the smaller file while keeping the readable one available for tooling.

The cost of that choice is duplication. Every data update has to be reflected in both directories, and a consumer that picks the wrong one gets either a slower site or a parse that reads the wrong thing. It is a simple, legible trade, and for a static asset pipeline it is a reasonable one.

The info.json file at the repository root sits alongside the other assets and is not documented in the excerpt, so its role is not stated here. It is the kind of file that carries a version or a build stamp, and given the absence of releases it is probably where a consumer would look to tell which game version the data matches.

The asset side, and the upstream data dependency

Three of the five top-level directories are assets rather than data, and the division is by purpose.

The icon directory holds the small square images that identify a path, an element, an item or a character. The image directory holds the larger artwork. The guide directory holds tutorial images, which is the set a fan site would use for walkthrough content, and that is the part most likely to be scraped from the game client and then re-published as a guide.

Splitting icons from full images from guides is the sort of organisation that only makes sense when the same assets are being served at different sizes in different places on a site, and when the site wants to fetch a hundred small icons without pulling a hundred large images.

The upstream dependency is the more important thing to notice. The README names Dimbreath/StarRailData as the game data source, which means the extraction and processing work happens in another repository and StarRailRes is downstream of it. For a consumer, that has a practical consequence: when the game updates, the data arrives in StarRailRes only after it has been extracted and processed elsewhere, and the timing of that is not something this repository controls.

It also means the two repositories can disagree for a while without either being wrong, since one holds the extraction and the other the published form.

For anyone planning to use this data, the sensible arrangement is to treat StarRailRes as a published artefact to consume, and to look at the upstream repository when you need to understand why a field is missing or a value changed, rather than assuming the published form is the whole story.

Where StarRailRes is the wrong choice

Three limits follow from what this repository is.

The first is that the data is a snapshot with a fixed layout. There is no versioned schema, no published API contract and no changelog for the index format. The files are maintained to match the game, so when the game adds a character or reworks a skill tree, the file set changes, and a consumer that assumed a stable field list will find out from a parse error or a missing entry rather than from a notice. That is fine for a site that tracks the game and rebuilds on update, and uncomfortable for a library that wants a long-term guarantee.

The second is the licence, and it deserves a paragraph of its own. AGPL-3.0 is the copyleft licence written for network services, and the question it asks is whether you serve the covered code or data to users over a network. For a site that hosts the index files and serves them to browsers, that is the case the licence was written for. Whether the JSON data files count as covered work, as opposed to the surrounding site code being covered, is a question for someone qualified, and the practical advice is to read the LICENSE file and get advice before you publish.

The third is that the game itself is not a free resource. Whatever the licence of this repository says, the underlying artwork, names and design belong to the publisher, and a repository of extracted game assets is a distribution of publisher material. A fan site using this for a non-commercial purpose is in a different position from a commercial product, and the readme does not address that, which is another reason the licence question is the one to settle early.

The alternative worth comparing against is building directly on the upstream data project and publishing your own derived index. That gives you full control over the format and the update cadence, at the cost of doing the extraction and the per-language processing yourself, which is exactly the work this repository exists to save you from.

Editorial conclusion

StarRailRes is a good fit for a fan site, wiki or tool that needs structured Star Rail data in a form it can serve directly, because the repository publishes the data already split into per-category, per-language JSON rather than leaving each consumer to scrape the game or parse the upstream dumps. It is a poor fit if you need live game data, since these are snapshot files that have to be regenerated as the game changes, and a poor fit if you need a stable contract, since the file layout is the contract and it is maintained to match the game rather than to a published schema version. Before building on it, check the index_new tree against the game version you are targeting, and read the LICENSE file, because AGPL-3.0 has consequences for a site that serves the data to browsers.

Frequently asked questions

Official sources

1. Issues
2. License: AGPL-3.0
3. Mar-7th/StarRailRes on GitHub
4. Project website
5. README