chrome_installer republishes Chrome offline installers as uncompressed EXE with SHA-256 sums

What the repository actually stores: two scripts, one data file, one workflow

The top level of the repository is small and worth reading in full: .github/, .gitignore, LICENSE, data.json, download.py, fetch.py and readme.md. So the publishing is a script that resolves Google's download metadata, a script that downloads the file, and a data file holding that metadata, with the GitHub Actions workflow in .github/ doing the scheduling.

The README is the generated output of that pipeline. It has one section per channel, Stable, Beta, Dev and Canary, and each section is a table with the same five columns: Architecture, Version, Size, SHA-256 and Download. Under every table sits a details block labelled for sha256sum -c containing the full digests with the file names, for example for the current Stable x64 build:

90f385e76ae2d728551f72e457a07f8ccb60d85494346e79c2f1bd401bd72aa0  x64_155.0.8059.80_chrome_installer_uncompressed.exe

Publishing machine-checkable sums next to the links is the design decision here. A build agent can consume the README or the workflow output without trusting a human copy-paste of a hash.

The files are Google's, uncompressed, hosted on dl.google.com

Every Download link in the tables resolves to a dl.google.com URL of the form:

https://dl.google.com/release2/chrome/adlprnv7saqjcdzfp7kop6nofxea_155.0.8059.80/155.0.8059.80_chrome_installer_uncompressed.exe

That tells you what the project is not doing. There is no modified Chrome, no repackaged MSI, and no binary hosted on GitHub releases in these tables. The archive of releases referenced at the top of the README is a stable release archive, but the artefacts it lists point back at Google.

The transformation is the uncompressed form. The file name suffix _chrome_installer_uncompressed.exe and the README title, Google Chrome Offline Installers (extract with 7-Zip), both indicate that the compression Google normally applies has been stripped so the file can be opened by an archiver rather than only run. The practical effect is that a machine without internet access can unpack the installer payload from a 7-Zip archive instead of executing a bootstrapping downloader that needs to reach Google's servers.

Sizes are listed in the tables, from 422.69 MB for Stable x86 up to 505.39 MB for Canary x64 in the current build, so anyone planning an air-gapped transfer knows roughly what to provision.

Four channels times three architectures, and the ARM64 question

Coverage is a grid: Stable, Beta, Dev and Canary, each with x86, x64 and ARM64 rows. In the current build the channel versions run 155.0.8059.80 for Stable, 156.0.8078.17 for Beta, 157.0.8092.0 for Dev and 158.0.8106.0 for Canary, so the channels are visibly ahead of each other in the usual way.

Architecture is the axis most likely to bite. The x86 row is a 32-bit binary and the x64 row is what almost every Windows machine wants, but Windows on ARM is the case people forget, and a repository that publishes an arm64 row for a channel saves you from discovering at install time that you grabbed the wrong one. File names make the architecture explicit, prefixing with x86_, x64_ or arm64_, so a script can select by name without parsing the table.

Note that the Canary and Dev channels are pre-release software by definition. A build pipeline that pins to those channels inherits their stability, and this repository does not add any qualification to them beyond the version and the checksum.

Verifying a download with the published sums

The README's details blocks exist to be used rather than read, and the label names the tool. Save the sums for the channel you want, save the download beside them under the exact file name the sum line uses, then let the checksum tool compare:

0926ac8f3182e3c244a715176662b192eade7a5eae36610ddf9d186f00cf483f  x86_155.0.8059.80_chrome_installer_uncompressed.exe
300d823840652519efff3ef1e2ee55f4438f1047ebd63709596c40b293f23fcd  arm64_155.0.8059.80_chrome_installer_uncompressed.exe

The file name in the sum line includes the architecture prefix and the full four-part version, which means the rename has to be exact. A file called chrome_installer.exe will not match, and getting that wrong produces a missing-file error rather than a checksum failure, which is a cheaper mistake than it sounds.

For automation, data.json in the repository root is the machine-readable counterpart to the tables. The README does not document its schema, so the safe assumption is that it carries the same version, size and hash fields the README renders, and you should inspect it before parsing rather than coding to a shape you have not seen.

Where this is the wrong tool

Three cases where reaching for this repository wastes your time.

If you need managed Chrome updates on a networked fleet, the Chrome enterprise update mechanisms exist for that and an offline installer does not replace them. An offline installer answers a one-time provisioning question, not a patching question.

If you want the installer to run itself, the README does not document running these files. Its title tells you to extract them with 7-Zip, which is a different workflow with a different set of assumptions about your tooling.

If you need provenance beyond a checksum, be clear-eyed about what the hash proves. The sums were computed by this project's workflow against files fetched from dl.google.com, so they detect corruption in transit or a truncated download. They do not independently attest to Google's build, and this repository is not a signature authority.

Platform scope is the fourth and simplest. Every artefact is a Windows .exe. There is no macOS or Linux coverage, and the repository name says as much.

Maintenance and licence

The repository is MIT licensed and not archived. The last push was on 2026-10-15, and the release tags show how the mirror moves with Google: 155.0.8059.80 on 2026-10-14, 155.0.8059.40 on 2026-10-06 and 154.0.8037.98 on 2026-10-06. Those tag dates are Google's release cadence showing through, not the project's own development rhythm.

That cadence is the upgrade cost to plan for. Upstream ships on its own schedule, so this repository is chasing versions rather than setting them, and any pinning logic you write against it needs a fallback when the file you expect has not been regenerated yet.

The primary language is Python, which explains the two-script layout and means anyone maintaining a fork has a small, readable surface to pick up. With only a handful of top-level files, the cost of running your own mirror instead of trusting this one is low.

Editorial conclusion

This repository is worth using when you need a Chrome installer on a machine with no internet-facing updater, or when a build pipeline wants a fixed download URL plus a checksum it can verify, and the four channel tables give you that per architecture. It adds nothing to Chrome itself: every download link points at dl.google.com, so you are still trusting Google, and the only added value is the uncompressed form and the published sums. Verify before adopting that the file you pulled still matches the sha256sum line in the README, and check that your architecture row exists, since ARM64 coverage depends on the channel, and note that the README documents 7-Zip extraction rather than a Chrome installer run.

Frequently asked questions

Official sources

1. Bush2021/chrome_installer on GitHub
2. Issues
3. License: MIT
4. README
5. Releases