How to Contribute Updates or Corrections to the Minecraft Launcher Comparison Site

The site accepts corrections and updates through the GitHub repository linked in its header. The comparison page itself states that the list is "maintained mostly by me and random contributions," that data "will inevitably get outdated over time," and that updates and corrections are always welcome. There is no on-page submission form or email address mentioned, so GitHub is the documented route. Because the site does not describe its contribution workflow, check the linked repository for the current process (issues, pull requests, or another channel) before submitting.

What the site says about its data

The page is explicit about the limits of its own accuracy:

• The launcher list and feature table are maintained mostly by one person, supplemented by random contributions.
• Data is expected to become outdated over time.
• Updates and corrections are welcomed, with the GitHub link in the header given as the place to go.

This matters when you spot an error: the site already anticipates that entries will drift, so a specific, verifiable correction is the kind of input it asks for.

What a useful correction looks like

The comparison table is organized by launcher (rows) and feature (columns). A correction is easiest to act on when it names both, states the current value, and gives the corrected value with a source.

The same pattern applies to other columns visible on the page, such as Look & Feel, Platforms, Languages, and Core Toolkits and Libraries. For a missing launcher, say which row should be added and supply the same feature values so it can be placed in the table consistently.

Step-by-step: submitting through GitHub

1. Open the GitHub link in the site header. This is the only contribution route the page names. Confirm which repository it points to before doing anything else.
2. Check for an existing issue or pull request covering the same launcher or feature. Duplicates slow down review, and an existing thread may already contain the maintainer's position.
3. Choose the channel the repository actually uses. If issues are enabled, an issue describing the correction is the lowest-friction option. If the repository expects pull requests for data changes, edit the relevant data file and open a PR. The site does not specify which, so follow what the repository shows.
4. Write the change as a before/after pair. Include the launcher name, the exact column, the current text, the proposed text, and a source link. Keep it to one topic per issue or PR where practical.
5. Verify the result. After the change is merged, reload the comparison page and confirm the row or column now shows the corrected value. If the page caches content, a hard refresh may be needed before the update appears.

Expected result: your correction is either merged into the table or discussed with the maintainer, and the public page reflects the agreed value.

Common sticking points

• No visible contribution instructions on the site. The page points to GitHub but does not spell out the process. Treat the repository's own README, issue templates, and contribution guidelines as the authoritative instructions.
• Corrections without sources. Because the maintainer cannot independently verify every launcher, a correction backed by an official project page, license file, or release note is far more likely to be accepted than an assertion alone.
• Disagreements about definitions. The page defines terms such as modloader support ("a way to install the modloader through the launcher directly, without downloading it separately") and explains CurseForge blocked downloads. If your correction depends on a different definition, quote the site's definition and explain why the entry does not match it.
• Scope creep. A single issue that rewrites many rows is harder to review than several focused ones. Split unrelated corrections.
• Stale local copies. If you are comparing against a saved copy of the page, re-check the live table first; the entry may already have been fixed.

When GitHub is not the right route

If the header link is broken or the repository has issues and pull requests disabled, the site offers no alternative contact method in the material shown. In that case, the practical options are to wait for the maintainer to reopen a channel or to keep your correction documented with sources so it can be submitted once a route exists. Do not assume an unlisted email or form is monitored.