mrkeyoor.com_
Sun 25 Oct 09:34 UTC
Dev Toolsevaluationupdated 25 Oct 2026

brotli review

Google Brotli is a lossless compression project with native build routes, a command-line program and a Python module. Its raw stream contains neither checksums nor the uncompressed data length. Applications that need integrity verification or an expected output size must handle those requirements around the stream.

Verdict

Google Brotli is a candidate when you need Brotli-format data and can handle integrity verification and framing around its raw stream. The measured checkout installed and built, but the sandbox's pytest run reported 299 passing tests and 22 failures. Investigate the missing-path regression errors and 2 audit findings against your deployment artifact. The supplied evidence does not establish full repository test coverage or the cause of the failures.

We ran it

Lab card: what happened when we ran brotliScreenshot of brotli (github.com/google/brotli)
Install✓ · 226s36 packages · 37 MB
Build✓ · 2s
Tests✗ · 18s299 passed · 22 failed of 321 (pytest)
Known vulns2(pip-audit)
Repo416 files~86,332 lines of source · 66.4 MB · 8 CI workflows · tests dir

Answers from our run

Does brotli build from source?

Dependencies installed in 226 seconds (36 packages), and the build succeeded in 2 seconds. We cloned commit 2e2bcf1 into a clean Debian container with 3 CPUs and no project-specific setup.

Do brotli's tests pass?

No. The project's own test command finished in 18 seconds and reported 299 passed, 22 failed (pytest).

Does brotli have known vulnerabilities in its dependencies?

pip-audit flagged 2 known advisories in the dependency tree at the time of our run.

Who should not use brotli?

Storage systems that expect successful decompression alone to detect every alteration to compressed data.

What are the alternatives to brotli?

Zstandard, zlib. Google Brotli is a candidate when you need Brotli-format data and can handle integrity verification and framing around its raw stream.

SetupN/AInstallation and build succeeded, but the supplied record lacks verified runtime versions and the failing invocation needed to assess the unresolved setup path.
DocsN/AThe supplied README extracts document format limits and installation requirements, but do not establish documentation coverage or a defensible numerical rating.
CommunityN/AThe supplied metadata and issue excerpts do not establish maintainer response quality, resolution times or support coverage.
MaturityN/AThe harness recorded 22 pytest failures, but its invocation, full repository coverage and the causes of those failures are not established.

Who it’s for

Developers whose integrations require Brotli-format data and already manage integrity and framing.
Python users prepared to validate the exact package they deploy.
Engineers able to investigate the file-metadata regression failures observed in the sandbox's pytest run.

Who it’s NOT for

Storage systems that expect successful decompression alone to detect every alteration to compressed data.
Applications that require the raw stream to contain the uncompressed length.
Python projects using interpreters older than 3.10, which the measured commit's Python documentation does not support.
Teams that require the sandbox's pytest run to pass before adoption: this run reported 22 failures.

Setup reality

The supplied sandbox record for commit 2e2bcf1 shows installation succeeded in 226 seconds, with 36 dependencies recorded and 37 MB on disk. The build succeeded in 2 seconds. The sandbox's pytest run failed with exit 1 after 18 seconds: 299 passed and 22 failed out of 321. Pip-audit reported 2 known vulnerabilities; the summary does not identify the affected package, severities or deployment exposure.

The sandbox ran on October 24, 2026, with 3 CPUs and 8 GB of RAM. Its image label was ghcr.io/astral-sh/uv:python3.12-bookworm, which does not verify the actual interpreter or operating-system version. The supplied evidence does not establish full repository test coverage across native, CLI and Python paths.

The Python README at commit 2e2bcf1 supports Python 3.10 and later. Its optional system-library route requires pkg-config and the brotlicommon, brotlienc and brotlidec components. The failure excerpt shows FileNotFoundError in file-metadata regression cases, including errors naming the path 'None', but does not establish the cause.

Brotli's raw stream leaves integrity checks to the application

Successful Brotli decompression does not prove that a compressed stream is intact. The Google Brotli README warns that changes to some raw ranges can go unnoticed by the decoder. The stream contains neither checksums nor the uncompressed data length.

Google Brotli is a lossless compression project with native build routes, a command-line program and a Python module. Consider it when your integration requires Brotli-format data and can supply the integrity verification and framing it needs. If you expect the raw stream to provide those properties, that expectation needs to change before integration.

What happened when we ran it

The supplied sandbox record covers commit 2e2bcf1 on October 24, 2026. Installation succeeded in 226 seconds, with 36 dependencies recorded and 37 MB on disk. The build succeeded in 2 seconds. The sandbox's pytest run failed with exit 1 after 18 seconds: 299 passed and 22 failed out of 321.

The failure excerpt names CopyStatRegressionTest cases under tests/regression/t01/copystat_regression_test.py. Permission-mode subcases report FileNotFoundError; several other failures name the missing path 'None'. The named cases concern mode propagation, special mode bits, timestamp copying and stdin or stdout handling. The excerpt does not explain why the paths were absent.

The supplied evidence does not establish full repository test coverage across native, CLI and Python paths. It also does not include the failing invocation. These results describe the tests executed by the harness, rather than certifying every supported integration.

The log summary reports 14.68 seconds, while the outer test-step measurement records 18 seconds. Neither duration is a compression benchmark. Pip-audit reported 2 known vulnerabilities, but the supplied summary does not identify the affected package, severities or deployment exposure.

The sandbox had 3 CPUs and 8 GB of RAM. Its image label was ghcr.io/astral-sh/uv:python3.12-bookworm; that label does not verify the interpreter or operating system actually used. The record therefore cannot support a diagnosis that attributes the failures to a particular runtime, platform or codec defect.

Check the Python package and native components you will deploy

The main README documents system packages and native source builds alongside Python installation. The Python README at commit 2e2bcf1 supports Python 3.10 and later.

That Python README also describes building against an installed system Brotli library instead of vendored sources. It requires pkg-config and all three components: brotlicommon, brotlienc and brotlidec. Choosing this route means checking the native components as well as the Python package.

The sandbox build result applies to the measured checkout. It does not establish equivalent behavior for every distribution package or Python wheel. Validate the artifact you intend to deploy. If your CLI workflow depends on preserved permissions or timestamps, include those properties in your checks because the observed failures concern file metadata.

Decide how to verify and frame the data

For a backup or transfer pipeline, define how the receiver will verify the recovered bytes against the intended data. Successful decompression alone is insufficient under the README's stream warning.

If your application needs an expected output size, provide it through the surrounding protocol or storage format. The raw stream described by the README does not contain that metadata. These are integration recommendations derived from the documented format boundary. The supplied lab record contains no corruption, adversarial-input or memory-use experiments.

Choose alternatives by format and workload

Zstandard offers dictionary training for related small records. Its README says training works when there is correlation within a family of small samples. Consider it when both ends can choose the format and your records fit that pattern. The supplied lab record contains no comparative throughput or compression-ratio measurements, so it cannot establish a performance winner.

zlib supports the zlib, DEFLATE and gzip formats. Choose it when an existing integration requires one of those formats.

For a Brotli integration, the next step is to validate a representative round trip with your deployment artifact, check metadata behavior if you use the CLI, and investigate the harness's missing-path errors and audit findings. Those checks remain work to do; this review does not report that they passed.

Alternatives

ProjectWhat it isPick it when
Zstandard gh↗A lossless compression library and command-line utility with dictionary training for related small records.Consider it when both ends can choose the format and your small records share patterns that suit dictionary training. Compare your own data before choosing settings; this lab supplied no comparative performance measurements.
zlibA general-purpose compression library supporting the zlib, DEFLATE and gzip formats.Choose it when your integration requires zlib, DEFLATE or gzip compatibility.

What people are saying

  1. [github-trending] google/brotli

Sources

  1. Google Brotli README
  2. Python documentation at measured commit
  3. Zstandard README
  4. zlib README

More dev tools reviews

agentskills · hallmark · ds-harness-remote · PCL · rpcs3 · shellcheck · the whole board →