Website carbon footprint: estimate, reduce and report it

I found two errors in the SWDM v4 formula used by our website carbon badge. They partly cancelled each other out, so tests that checked only whether one result was greater than another did not catch them. Comparing the calculations with a reference library exposed the problem.

Website carbon calculators estimate emissions using models. Their outputs are not direct measurements of energy used by a particular device, network and server. This guide explains the SWDM v4 assumptions, the difference between first and repeat visits and how to compare results after making changes.

Website carbon calculator (SWDM v4)

A website carbon calculator multiplies transfer in GB by 0.300 kWh/GB and 494 gCO₂e/kWh, which means about 0.15 gCO₂e for 1 MB of first-view transfer (SWDM v4). You can also add monthly page views, the share of returning visits and green hosting. The calculation runs in your browser, and the values you enter stay on your device.

You'll find the transfer in the DevTools Network tab, where you disable the cache, reload the page and take the "transferred" total. Uncompressed file sizes from disk will overstate the result.

The calculator's tests check six cases from the research pack to six decimal places, for example 0.148200 gCO₂e for 1 MB, 0.296400 g for 2 MB and 0.155399 g for 1 MiB (1,048,576 bytes). Nitpicking? A MiB is almost 5% bigger compared with a MB, and a GiB is over 7% bigger compared with a GB. That's exactly what both badge bugs looked like:

What a website carbon footprint includes

A website carbon footprint is an estimate of the greenhouse-gas emissions tied to delivering and using a website, within a stated boundary and period. For a shorter definition, see the website carbon footprint glossary entry.

The estimate covers electricity along the whole delivery chain, from the server to the visitor's device, plus an allocated share of hardware manufacturing. CO₂e means carbon dioxide equivalent, greenhouse gases expressed in one common unit. A result per page view is a rate, and a monthly footprint also needs your traffic data. The Green Software Foundation's SCI for Web project explicitly covers third parties too.

A low estimate only tells you about emissions. Your site's accessibility needs separate evidence, and so do water use and the hardware supply chain.

Calculators, standards and energy measurement answer different questions

Start with transfer and a browser profile, because you can see those right away, and add the model only when you compare.

The W3C Web Sustainability Guidelines (WSG, a Group Note Draft as of September 2026) are a list of design practices. You'll need other tools to calculate emissions.

How SWDM v4 works

The Sustainable Web Design Model v4 (SWDM v4) is an open model that uses transfer to allocate, meaning it assigns your page part of the energy and emissions of three segments: data centres, networks and user devices. Each segment has an operational and an embodied part (hardware manufacturing), and the Green Web Foundation's CO2.js is one implementation of the model.

The total is 0.300 kWh-equivalent per 1 GB at a base factor of 494 gCO₂e/kWh (SWDM v4 methodology). The embodied part is an energy equivalent the model assigns, without measuring the electricity your page used. The 494 is a constant of this model version, and a location-specific operational factor will change the estimate.

Worked example: 1 MB, first view

This is pure model arithmetic for 1,000,000 bytes (0.001 GB) of first-view transfer, without cache or a hosting adjustment, and without measuring cometweb.io or a customer's site.

Data: 1,000,000 / 1,000,000,000 = 0.001 GB
Allocated operational + embodied-equivalent coefficient: 0.300 kWh/GB
Estimated emissions: 0.001 × 0.300 × 494 = 0.1482 gCO2e

In a headline or lead, write about 0.15 gCO₂e per modelled first view. The six decimals are only there so you can reproduce the calculation.

The formula and its limits are in the calculation notes and reproducible examples, whose script calculates independently of CO2.js.

SWDM v4 allocates emissions by transfer, while networks use power differently

SWDM v4 is an attributional estimate, a rule for splitting a bigger system's footprint, and network power doesn't rise in step with megabytes. Research by Mytton and co-authors describes the high baseline power of network equipment and shows why a simple kWh/GB is a poor stand-in for the causal response of a network to a change in traffic.

The Green Web Foundation also describes transfer as a proxy with its own limits, which leads to two very different sentences:

• fine: "under SWDM v4, cutting transfer from 2 MB to 1 MB halves the allocated estimate for the same assumptions";
• too strong: "removing 1 MB from this page cuts the network's physical power draw exactly in half".

Translation: the model tells you how much to allocate to a page. How much electricity you actually save only shows up when you measure the specific system.

Why two website carbon calculators show different CO₂e

The arithmetic is usually the same, and it's the configuration that differs. Compare the model version, how transfer was collected, cache, third parties, when the test stopped, the electricity intensity, the hosting rule and the boundary, meaning one URL or a whole task.

CO2.js v0.18.0, released in February 2026, switched the default model to SWDM v4 (release guide). So a library upgrade on its own can shift your data series. Record the model version and the raw transfer, don't overwrite old results, and to compare, recalculate both periods under a common version as a restatement.

Repeated scans show you how transfer varies, but they leave the coefficient untested, because they all share it. That's why the badge tests passed. Test uncertain assumptions with scenarios, because a confidence interval needs a defensible probability model. Don't average the results of different models, such as EcoIndex and SWDM.

Cache: a first view and a return visit are two scenarios

In CO2.js you set the share of returning visits and dataReloadRatio, the portion of data downloaded again. In this example a return visit downloads 20% of the first-view bytes.

Visit multiplier = first-view share + return-view share × reload share
                 = 0.5 + 0.5 × 0.2
                 = 0.6

Modelled average-view estimate = 0.1482 × 0.6 = 0.08892 gCO2e

20% reloaded and 20% cached are opposite assumptions, and the CO2.js SWDM v4 implementation documents the difference itself. With 20% reloaded, 80% of the first-view data stays in the cache.

Either measure cold and warm visits separately and weight them by traffic, or take first-view bytes and apply an explicit cache model. Don't do both, because a double "cache saving" will understate the result, and a cached page still renders and runs code.

Collect the right bytes

Record your method, because browser Resource Timing, browser network logs and server logs see different traffic. According to Resource Timing and MDN's 0 docs:

• PerformanceResourceTiming.transferSize is 0 when a resource came from the local cache;
• cross-origin resources hide some data without a Timing-Allow-Origin header;
• redirects, service workers and CDN cache shift the boundary of the test.

Missing data is missing data, and you have to prove a zero before you report one. Label a total from an incomplete resource list as partial.

In SWDM v4, green hosting only lowers the operational data-centre part

In SWDM v4, the greenHostingFactor flag changes the operational data-centre contribution, while the network, the device and embodied emissions all stay in the result.

For a first view, the adjustment changes the total by about 18.3% against the same scenario without it. In this model, the adjustment accounts for less than one fifth of the estimate; it does not bring the modeled value close to zero. That result follows from the formula and the chosen coefficients. It is not an observed reduction from changing hosting providers. In a real service the effect depends on the provider's evidence and your calculation boundary.

Green Web Foundation verification is an accounting of the provider's energy based on its evidence, and measuring a single request takes a different tool. The status covers your server, so external video, fonts or APIs sit outside it.

From 1 October 2026, the Green Web Foundation doesn't accept offsets as a basis for verification. A status granted earlier may have rested on them, so check the provider's evidence period before you make a public claim.

Website carbon footprint for a whole site: weight page groups by traffic

Your homepage can be light while search, checkout or a dashboard does far more work. Group routes by how they behave, measure each group with the same scenario and weight the results by traffic from the same period.

Estimated total for covered traffic = sum(views_i × estimate_per_view_i)
Traffic-weighted mean = estimated total / total covered views

Don't mix your denominators, because a page view is a different unit from a session or a purchase. Separate bots and background jobs from your human visits. The Green Software Foundation's SCI for Web Assembly Report assigns the boundary to the observed activity, so a human page-view model attached to every server request will inflate your result.

Intensity can fall while the total rises

Below are the same coefficients, with a hypothetical change from 2 MB to 1 MB per first view.

Intensity fell by 50% against the "before" period, while the modelled total rose by 25%, though the reason traffic went up is invisible to the calculation. So a report saying "gCO₂e per view halved" tells only half the story. Report both, meaning the intensity per unit and the total for a documented volume.

What to optimise to reduce a website's carbon footprint

Start with work you can see and measure again, keeping in mind that none of these steps comes with a universal emissions-reduction percentage.

1. Remove unnecessary transfer, which means cutting oversized images, unused fonts, videos that start on their own and scripts nobody owns. Still load the likely Largest Contentful Paint (LCP) image right away. web.dev's LCP guide warns that loading a necessary image late hurts the experience, and its transfer doesn't go anywhere.
2. Don't break your fonts, so check character coverage after subsetting, as web.dev's font best practices recommend. I covered the details in my WOFF2 vs TTF guide.
3. Measure browser work alongside megabytes, because a 100 kB image and 100 kB of JavaScript that polls the server for minutes are different workloads. Check long tasks and polling, on an older device too.
4. Check that your cache actually works by looking at real CDN hits and misses and at transfer on return visits. Count speculative loading separately, because according to MDN wrong predictions increase total work and transfer.
5. Inspect backend and third-party demand, because a bytes model is blind to an expensive database query, unbounded retries or an AI call with a small response. Count resources per completed task, failed attempts included.
6. Assess hosting with evidence. PUE describes facility overhead relative to IT equipment. Apply it only when your input energy doesn't already include it, or you'll count the overhead twice (SCI specification).

Captions, text alternatives and security controls stay, because the WSG treat sustainability together with accessibility and security. A page-weight threshold is your product rule, because no sustainability standard sets a universal one.

Carbon footprint of a web application: count it per task (SCI)

A checkout or a generated report involves the browser, several APIs and databases. For that question a component calculation based on Software Carbon Intensity (SCI), a standard tied to ISO/IEC 21031:2024 (SCI), fits better. In mid-September 2026 SCI for Web was labelled Draft.

Carbon intensity = (sum of component operational emissions
                    + allocated embodied emissions) / successful tasks

Component operational emissions = energy × appropriate carbon intensity

Don't add a full SWDM estimate to a measured backend total without checking for overlap, because the page model already allocates a data-centre contribution. Keep your practice score apart from carbon, and report coverage and uncertainty next to it, because one glued-together "sustainability number" leads straight to greenwashing.

How to report a website carbon footprint without greenwashing

With every public result, record enough that someone else can rebuild the estimate:

Statements the calculator result supports:

• "SWDM v4 estimates 0.15 gCO₂e for a first view at 1 MB of transfer and the recorded assumptions."
• "First-view transfer fell from 2.0 to 1.2 MB. With the same model configuration, the SWDM estimate fell proportionally."
• "The result covers the data centre, network and device within the model's boundary. It isn't a direct measurement of infrastructure power."
• "Hosting status was checked with the Green Web Foundation on date X; external providers weren't covered by that verification."

A defensible statement for the 2 MB and 1 MB example:

Under the stated SWDM v4 assumptions, reducing the tested first-view transfer from 2 MB to 1 MB lowers the modelled estimate from 0.2964 to 0.1482 gCO₂e per view. These figures describe an illustrative calculation, not measured electricity savings or a complete website lifecycle footprint.

Statements the calculator result is too weak for:

• "the page emits exactly 0.1482 gCO₂e";
• "we removed 1 MB, so the network now uses half the energy";
• "green hosting means zero emissions";
• "the site is climate neutral";
• "an A rating means conformance with a W3C standard";
• "the saving equals exactly X flights or Y trees" without your own, disclosed method for those equivalents.

If you use an A+–F scale, record whose scale and which thresholds you apply. The SWDM/CO2.js Digital Carbon Ratings have their own thresholds, and a tool can have a separate presentation scale.

How to re-test a website carbon footprint after optimising

Before you ship, record a baseline, meaning the scenario (task, device with browser, consent, first view or return visit), raw transfer with request count, the SWDM/CO2.js version with hosting adjustments, the date, the modelled result and whatever's out of scope.

After the release, repeat the same scenario and compare transfer, JavaScript execution and whether the user's task succeeded first, and only then compare CO₂e under the same method. The Polish edition's research pack has a measurement sheet and a before/after comparison template (both in Polish).

Where the Ecology module in CometWeb Insight helps

Across many pages, the Ecology module in CometWeb Insight, our website audit app, calculates a modelled SWDM v4 estimate with disclosed assumptions, shows each resource and its effect on estimated CO₂e, checks hosting with the Green Web Foundation and compares a re-scan in the same scenario. The A+–F letters are our own presentation scale, while the emissions come from SWDM v4.

The open-source CometWeb Carbon Badge can show the result publicly and should communicate its method and date, though it isn't an ESG certificate. That's where the two bugs from the start of this article lived, and today its tests check an absolute value, where 1 GB is 148.2 gCO₂e, or 0.1482 g per MB.

A page can download less data and still run more expensive JavaScript, so put the ecology result next to a website speed measurement. If you want to check the weight and estimated CO₂e of many pages at once, create an Insight account and run your first audit.

Three takeaways

1. The number is easy, because it's transfer in GB times 0.300 kWh/GB times 494 gCO₂e/kWh, and the calculator does it for you.
2. The hard part is everything around the number, because you can only compare two results with the same boundary and the same scenario. The model version has to match as well.
3. Describe the carbon effect only as far as your evidence goes. You can measure lighter transfer in DevTools, but an electricity saving only shows up when you measure the specific system.

And if you're writing your own calculator, pin it to reference numbers. Mine was wrong in two directions at once for a while.

Frequently asked questions

Sources

The worked examples and workflow draw on CometWeb's Web Sustainability v15 materials (5 September 2026, a methodology specification without production validation) and on the sources below.

1. Sustainable Web Design: Estimating Digital Emissions. SWDM v4, segments, coefficients and cache assumptions.
2. CO2.js v0.18.0: release. Default model switched to SWDM v4, February 2026.
3. CO2.js: SWDM v4 implementation. Hosting, visits and raw segment semantics; the exact inspected blob identifier is recorded in the calculation notes.
4. Mytton, Lundén and Malmodin: Network energy use not directly proportional to data volume. Journal of Industrial Ecology, 2024; network-power methodology.
5. Green Software Foundation: SCI. Software Carbon Intensity and ISO/IEC 21031:2024.
6. Green Software Foundation: SCI for Web. Project labelled Draft; web boundary and relationship to the parent SCI.
7. Green Software Foundation: SCI specification. Functional unit, operational and embodied emissions, baseline comparison and exclusions.
8. W3C: Web Sustainability Guidelines. Group Note Draft, as of September 2026.
9. W3C: Resource Timing. Browser resource sizes and access restrictions.
10. Green Web Foundation: What we accept as evidence of green power. Supplier evidence and verification scope.
11. Green Web Foundation: Are offsets allowed as evidence for verification?. Change effective 1 October 2026.
12. Sustainable Web Design: Digital Carbon Ratings. External A+–F scale based on SWDM v4.

This article describes technical estimates. It isn't a measurement of any specific infrastructure's energy, a complete lifecycle assessment, an ESG audit or an environmental compliance claim.