JavaScript library for estimating the carbon emissions of digital services and website visits.
- Pricing
- Free
- Category
- Carbon-Aware Computing
- Compliance
- Not stated
Use case
What engineering teams should verify before building carbon or energy calculations on open-source libraries and APIs.
Engineering teams increasingly embed emissions estimates directly into their own products: a website carbon calculator, a CI pipeline that reports the cost of a build, a dashboard that shows emissions per model or per customer. Open-source libraries make this possible without a commercial contract, but they shift a set of obligations onto the team that adopts them: the licence, the maintenance of the project, the data behind the calculation and the reproducibility of the number that eventually reaches a report.
The libraries differ in scope. CO2.js converts bytes or page views into estimated emissions for web and digital services. CodeCarbon measures energy and emissions from compute workloads. BoaviztAPI models the life-cycle impacts of hardware. The SCI specification, published by the Green Software Foundation, provides the method that ties energy, location-based carbon intensity and embodied emissions into a single rate. Each library depends on external datasets for grid intensity or embodied factors, and those datasets change.
The common failures are engineering failures rather than modelling failures. A licence that is incompatible with a hosted product, a dependency that has not been released in years, a hard-coded national grid average that cannot be replaced with a regional or hourly dataset, or an output that cannot be reproduced because the factor version was never pinned. Method documentation is often thin, and units are easy to misread.
Evaluate libraries on licence compatibility, maintenance activity, data source replaceability, integration cost and reproducibility. A library that cannot be audited is not cheaper than a vendor, it just moves the work.
Licence compatibility
Check the project licence and its obligations for hosted or distributed products, including copyleft implications, and review the licences of transitive dependencies before embedding the library in a commercial service.
Maintenance activity and bus factor
Look at recent releases, commit cadence, issue responsiveness, number of active maintainers and security updates, and decide whether the team can fork and maintain the project if it stalls.
Data source replaceability
Grid intensity and embodied factors should be configurable, so a regional, hourly or internally approved dataset can replace a hard-coded average, with the factor version recorded alongside each result.
Embedding in existing systems
Consider language and runtime, API stability, dependency footprint, offline operation and throughput, because a calculation library called on every request has different constraints from one run in a batch job.
Method transparency and units
The formula, boundaries and units should be documented and consistent with the SCI or GHG Protocol definitions the organisation reports under, including what is excluded and how uncertainty is expressed.
Versioning and reproducibility
Pin library and dataset versions, keep a snapshot of the factors used per reporting period, and verify that the same inputs produce the same outputs months later when someone asks how a figure was calculated.
JavaScript library for estimating the carbon emissions of digital services and website visits.
Open-source Python library that estimates the carbon emissions of compute.
Open API for assessing the environmental impacts of servers, cloud instances and ICT equipment.
Open-source tool for measuring and reducing cloud emissions across AWS, Azure and Google Cloud.
Python toolkit for building software-defined power meters at application and container level.
Last verified 2026-10-22. Figures on the linked tools are checked against the sources above; confirm pricing and compliance coverage before signing.