SWDM v4 Explained: How Website Carbon Is Calculated

Every credible website carbon calculator — Carbon Badge, Website Carbon Calculator, CO2.js — produces its number from the same underlying model: the Sustainable Web Design Model, currently on version 4. If you have ever wondered where the 0.194 figure comes from, why the world average grid intensity is 494 and not some other number, or what exactly the green factor is adjusting for, this article answers those questions in full.

This is a technical article. I will show you the actual math, trace each constant back to its source, work through concrete examples, and be honest about where the model breaks down. SWDM v4 is genuinely useful — it is also genuinely an approximation, and understanding the difference between the two makes you a better user of any tool that relies on it.

A Brief History: SWDM v1 Through v4

The model did not arrive fully formed. Its history matters because each version represents a deliberate methodological choice, and understanding those choices explains why the current constants are what they are.

v1 — 2019: Establishing the Framework

Wholegrain Digital published the first version of the Sustainable Web Design Model in 2019. At the time, there was no commonly accepted methodology for calculating website carbon emissions. The field was scattered: some tools used data centre energy alone and ignored end-user devices entirely, others applied ad-hoc factors with no published sourcing. Wholegrain's contribution was to define a consistent, transparent, source-cited framework that covered the full data transfer chain.

v1 identified three segments — data centres, networks, and end-user devices — and published energy coefficients for each derived from the best available research at the time. The primary academic sources were Andrae and Edler's 2015 paper "On Global Electricity Usage of Communication Technology", Shift Project research on digital sobriety, and IEA energy statistics. The framework was open from day one, published under Creative Commons, which allowed other tools to adopt and cite it.

v2 and v3 — Refining the Coefficients

The 2020 and 2021 iterations refined the energy coefficients as newer IEA data became available and the underlying research literature expanded. v2 in particular adjusted the network segment downward to reflect improving efficiency in fixed-line and mobile core networks. v3 incorporated feedback from the wider digital sustainability community and clarified the methodology for handling returning visitors with cached assets — a real-world scenario the original model did not address cleanly.

Each version maintained backward compatibility in framework terms — the three-segment structure remained constant — while updating the numbers to track evolving infrastructure efficiency. This is important context: the coefficients are not arbitrary. They are anchored to empirical research and get updated as that research matures.

v4 — 2024: The Current Standard

SWDM v4, published in 2024 by Wholegrain Digital in collaboration with the Sustainable Web Design community, represents the most significant methodological update to date. Key changes from v3 include updated energy coefficients reflecting more recent IEA and Shift Project data, a revised carbon intensity figure sourced from Ember Climate's 2023 global electricity review, and a more rigorous treatment of the green hosting factor — moving from a binary on/off to a model-level factor (0.243) that represents the proportion of web traffic already served by verified renewable infrastructure globally.

v4 is the version Carbon Badge implements. When you run a scan and see a gram-per-pageview figure, you are seeing the output of the v4 formula applied to your page's measured data transfer. The SWDM v4 measurement guide covers how to run that calculation manually if you want to verify any tool's output independently.

The Core Formula, Decomposed

The complete SWDM v4 formula for CO₂ per pageview is:

CO₂ (grams) = data_transfer_GB × energy_per_GB × carbon_intensity × (1 − green_factor)

Substituting the actual values:

CO₂ (grams) = data_transfer_GB × 0.194 × 494 × (1 − green_factor)

Or with the constants pre-multiplied:

CO₂ (grams) = data_transfer_GB × 95.836 × (1 − green_factor)

Four inputs. Let's take each one apart.

Component 1: Data Transfer in Gigabytes

Data transfer is the only variable in the formula that is specific to your page. Everything else is a constant derived from global averages. The transfer figure is what makes SWDM v4 a tool for comparing websites rather than just producing a single industry-wide number.

"Data transfer" means the total bytes transferred over the network when a user loads your page for the first time with an empty browser cache. This includes every resource the browser requests:

• HTML — the document itself
• CSS — all stylesheets, including those loaded by @import rules
• JavaScript — every script, inline and external, including deferred and async
• Images — everything in the initial viewport that loads eagerly; lazy-loaded images that never appear are not counted
• Fonts — web font files, typically WOFF2
• API responses — JSON or other data loaded by JavaScript on the initial page render
• Third-party resources — analytics scripts, chat widgets, advertising pixels, social embeds

The critical detail: transferred size, not resource size. These are different numbers. The resource size is the raw bytes of each file. The transferred size is what actually crosses the network after compression (gzip or Brotli). A 300 KB JavaScript file might transfer as 90 KB with Brotli compression. The 90 KB is what matters for the carbon calculation, because that is the actual data moving through the network and energy-consuming infrastructure.

In Chrome DevTools' Network panel, this distinction appears as two columns: "Size" (transferred, compressed) and "Content" (uncompressed resource). Always use the "Size" column for carbon purposes. The status bar at the bottom of the panel shows the aggregate: something like 2.1 MB transferred, 7.8 MB resources. The 2.1 MB is your input.

Convert to GB for the formula. 1 MB = 0.001 GB. 2.1 MB = 0.0021 GB. That is the data_transfer_GB value.

Component 2: Energy per Gigabyte (0.194 kWh/GB)

This constant represents the average energy consumed, across all infrastructure, to transfer one gigabyte of data from server to screen. It is the sum of three segment-specific coefficients:

Data Centres: 0.055 kWh/GB

The data centre coefficient covers the energy consumed by servers and their associated cooling and power delivery infrastructure to store, process, and serve your files. The number is derived from IEA data on global data centre electricity consumption divided by global internet traffic volume — a top-down estimate rather than a measurement of any individual facility.

PUE (Power Usage Effectiveness) matters here. A perfect PUE of 1.0 means every watt drawn by the facility goes directly to compute. Real data centres range from about 1.1 (hyperscaler facilities like Google and AWS, which are highly optimised) to 2.0 or higher (older on-premise facilities and co-location data centres with inefficient cooling). The global average used in SWDM v4 sits around 1.58, reflecting the mix of hyperscaler and non-hyperscaler infrastructure serving web traffic globally.

This coefficient has decreased over successive SWDM versions as data centres have become more efficient. The massive shift toward hyperscale cloud (where PUE is much lower) and the aggressive efficiency investments by Google, Microsoft, and Amazon have pushed the average down. If the trend continues, future SWDM versions may revise this coefficient further downward.

Network Transmission: 0.059 kWh/GB

The network coefficient covers everything between the data centre and the user's device: core internet routers, internet exchange points, submarine cables, terrestrial fibre, ISP infrastructure, Wi-Fi routers, and mobile base stations. This is an average across wired and wireless delivery — and the wireless side pulls the average up significantly.

Fixed-line broadband (fibre, cable) uses roughly 0.04 kWh/GB for the access network. Mobile 4G LTE uses approximately 0.1 kWh/GB — roughly 2.5× more energy per gigabyte, because radio transmission is inherently less efficient than optical fibre and base stations must be continuously powered regardless of traffic load. 5G networks are more efficient per bit at high utilisation but consume more energy at the base station level, making their real-world efficiency advantage over 4G context-dependent.

The 0.059 figure is a weighted average reflecting the global mix of wired and mobile traffic. As mobile's share of internet traffic continues growing and as networks upgrade from 4G to 5G, this coefficient may shift in future versions.

End-User Devices: 0.080 kWh/GB

This is the segment that surprises most people. End-user devices — the laptop, phone, or tablet receiving and rendering your page — consume the largest share of the energy modelled by SWDM v4. The coefficient is derived by estimating average device power consumption during data transfer and dividing by typical data rates.

Different device types have very different power profiles. A modern M3 MacBook Pro in active use draws roughly 15–25W. A mid-range Android smartphone draws 2–4W during browsing. A desktop PC with a 27-inch monitor draws 60–100W. SWDM v4 uses a weighted average across the global device mix, reflecting the fact that desktop-class devices, despite being a minority of browsing sessions by count, consume a disproportionate share of energy per session.

The practical implication: the user's device contributes more to per-pageview emissions than either data centres or the network, yet it is entirely outside the web developer's direct control. This is one of SWDM v4's known limitations — the model uses the global average device, not the actual devices your audience uses.

Component 3: Carbon Intensity (494 gCO₂/kWh)

Carbon intensity is the number of grams of CO₂ equivalent emitted per kilowatt-hour of electricity generated. It varies enormously by country and grid: France's nuclear-heavy grid runs at roughly 60 gCO₂/kWh. Poland's coal-dependent grid runs above 700 gCO₂/kWh. The global average, weighted by electricity generation volume across all countries, was 494 gCO₂/kWh according to Ember Climate's 2023 global electricity review.

This is the figure SWDM v4 uses: a single global average applied uniformly, regardless of where your server is hosted or where your users are located. A server hosted in Iceland (geothermal grid, near-zero carbon) and a server hosted in China (coal-heavy grid, 570+ gCO₂/kWh) both get the same 494 coefficient in the formula.

This is a deliberate simplification. The alternative — using location-specific carbon intensity for each server and each user — would require knowing your CDN node locations, your users' geographic distribution, and real-time grid mix data for each location. That information is simply not available in a standardised way for web-scale use. The global average produces a consistent, comparable result across all websites. Comparability is what makes the formula useful as a benchmarking tool.

The 494 figure will likely shift in future SWDM versions as global grids decarbonise. Ember Climate's 2024 preliminary data suggests the average has moved slightly lower, reflecting renewable capacity additions globally — though the rate of renewable deployment is unevenly distributed, and coal still dominates electricity generation in large developing economies.

Component 4: The Green Factor (0.243)

The green factor is the most frequently misunderstood component of the formula. It is not a binary flag that turns on a discount. It is a model-level constant representing the estimated proportion of global web traffic already served by verified renewable infrastructure.

SWDM v4 sets this at 0.243 — meaning approximately 24.3% of internet traffic is estimated to be served by data centres using verified green energy. This figure comes from the Green Web Foundation's database of green-certified hosting providers, combined with estimates of their traffic share.

The formula applies this factor as follows:

-- Non-green host: green_factor = 0
CO₂ = data_transfer_GB × 0.194 × 494 × (1 − 0) = full calculation

-- Green host: green_factor = 0.243
CO₂ = data_transfer_GB × 0.194 × 494 × (1 − 0.243) = 75.7% of full calculation

In plain terms: if your hosting provider is verified by the Green Web Foundation as using renewable energy, the formula credits you with a 24.3% reduction in calculated CO₂. If your host is not verified, you get no reduction — even if they claim to use renewables, even if they actually do. The formula requires verified documentation, not self-reported claims.

The verification check is practical: query https://api.thegreenwebfoundation.org/greencheck/yourdomain.com and look for "green": true in the JSON response. Carbon Badge does this automatically during a scan. The database covers major providers — Google Cloud, AWS (partially), Hetzner, Infomaniak, GreenGeeks, and several hundred others — but smaller regional hosts that use renewables may not be listed if they have not submitted documentation to the Green Web Foundation.

One nuance worth understanding: "green hosting" typically means the provider purchases Renewable Energy Certificates (RECs) or Power Purchase Agreements (PPAs) matching their consumption, not that a wind turbine is physically connected to their server room. RECs are a legitimate and widely used instrument for tracking renewable energy procurement. Whether they represent genuine additionality — whether the renewable energy purchased would exist without the demand from data centres — is a more complex debate in energy economics. For the purposes of SWDM v4, GWF verification is the accepted standard.

Worked Examples: The Math in Practice

Theory is clarified by numbers. Here are four examples worked in full.

Example 1: 500 KB Page, Non-Green Host

Page weight: 500 KB = 0.0005 GB
Green factor: 0 (non-green host)

CO₂ = 0.0005 × 0.194 × 494 × (1 − 0)
     = 0.0005 × 95.836
     = 0.04792 gCO₂
     ≈ 0.048g CO₂ per pageview  →  Grade A

A well-optimised 500 KB page earns a solid A grade. To put that in context: you would need roughly 3,000 pageviews to produce 1 gram of CO₂. A site at this weight with 100,000 monthly pageviews emits about 4.8 kg CO₂ per year.

Example 2: 2.5 MB Page, Non-Green Host

Page weight: 2.5 MB = 0.0025 GB
Green factor: 0 (non-green host)

CO₂ = 0.0025 × 0.194 × 494 × (1 − 0)
     = 0.0025 × 95.836
     = 0.23959 gCO₂
     ≈ 0.240g CO₂ per pageview  →  Grade B

The global median page weight. A B grade — better than average, but with meaningful room to improve. The HTTPArchive Web Almanac records median desktop page weight at approximately 2.3 MB in 2024, so this example closely represents a typical unoptimised but not egregious website.

Example 3: 2.5 MB Page, Green Host

Page weight: 2.5 MB = 0.0025 GB
Green factor: 0.243 (verified green host)

CO₂ = 0.0025 × 0.194 × 494 × (1 − 0.243)
     = 0.0025 × 95.836 × 0.757
     = 0.18145 gCO₂
     ≈ 0.181g CO₂ per pageview  →  Grade B (lower end)

Same page, same content, same user experience. Simply migrating to a verified green host drops this from 0.240g to 0.181g — a 24.6% reduction. That is a change in a server configuration, not a line of code.

Example 4: 5 MB Page, Non-Green Host

Page weight: 5 MB = 0.005 GB
Green factor: 0 (non-green host)

CO₂ = 0.005 × 0.194 × 494 × (1 − 0)
     = 0.005 × 95.836
     = 0.47918 gCO₂
     ≈ 0.479g CO₂ per pageview  →  Grade C (high end)

A 5 MB page sits just inside a C grade. Pages at this weight are common on e-commerce sites with multiple uncompressed product images. On a site with 50,000 monthly pageviews, this produces about 24 kg CO₂ per year — equivalent to driving a petrol car roughly 100 km every month, indefinitely, just from page loads. The reduction guide documents what it takes to cut a page from 5 MB to under 1 MB.

How Carbon Badge Implements SWDM v4

Understanding the formula is one thing. Understanding how a tool translates it into a usable measurement is another. Here is what happens when you run a scan on Carbon Badge:

1. Fetch simulation. The scanner requests your page the way a real browser would — following redirects, loading all resources in the document, including those triggered by JavaScript execution. It captures the total bytes transferred (compressed, over-the-wire) across all requests: HTML, CSS, JS, images, fonts, API responses, third-party resources.
2. Green Web Foundation check. The scanner queries the GWF API for your domain. The response determines whether green_factor is 0.243 or 0. If your domain is not found, the factor defaults to 0.
3. Formula application. CO₂ = data_transfer_GB × 0.194 × 494 × (1 − green_factor). The result is rounded to three decimal places and displayed in grams per pageview.
4. Grade assignment. The gram figure is mapped to a letter grade using the thresholds: A (<0.15g), B (0.15–0.30g), C (0.30–0.50g), D (0.50–0.75g), E (0.75–1.00g), F (>1.00g).

The scan represents one uncached first visit. Carbon Badge does not currently model returning visitor caching, which — as we will discuss in the limitations section — is one of the known gaps in the SWDM v4 framework as typically implemented by tools.

Limitations and Criticisms

Intellectual honesty requires covering what the model gets wrong, not just what it gets right. SWDM v4 has real limitations, and understanding them is essential for interpreting your results correctly.

1. It Uses Averages, Not Real Measurements

Every constant in the formula is an average. The energy per GB (0.194) is an average across all data centres, all networks, and all devices globally. The carbon intensity (494 gCO₂/kWh) is a global grid average. The green factor (0.243) is an estimate of renewable traffic share.

Your actual emissions might be 30% higher or 30% lower than what SWDM v4 calculates, depending on where your servers are hosted, what type of network your users predominantly use, and what devices they use to access your site. A site primarily accessed by mobile users in India (4G networks, coal-heavy grid) will have higher real emissions than the formula suggests. A site accessed by desktop users on green-powered European fibre will have lower real emissions.

SWDM v4 is a benchmarking tool, not a carbon accounting instrument. It produces a number that is consistent and comparable across websites — which is valuable — but not precise in an absolute sense.

2. Device Type Is Not Differentiated

The end-user device coefficient (0.080 kWh/GB) is a weighted global average. It does not vary based on whether your users are on desktops, laptops, tablets, or phones. But the real energy difference between these is significant: a desktop PC with a large monitor draws 4–8× more power than a smartphone. A site primarily accessed on mobile emits less at the device level than the formula implies; a site primarily accessed on desktops emits more.

If you have GA4 or similar data showing your device mix, you have better information than the global average — but there is currently no standard way to feed that into SWDM v4 without departing from the published methodology.

3. Network Type Is Not Differentiated

Similarly, the network coefficient (0.059 kWh/GB) averages across wired and mobile delivery. Mobile networks consume approximately 2.5× more energy per GB than fixed-line broadband. A site with 70% mobile traffic has higher real network emissions than one with 70% desktop/Wi-Fi traffic, but the formula treats them identically.

4. Geographic Grid Mix Is Not Applied

The 494 gCO₂/kWh figure is a global average. A server in Norway (grid: ~15 gCO₂/kWh, almost entirely hydroelectric) produces vastly less actual carbon than a server in Poland (grid: ~700 gCO₂/kWh, primarily coal). SWDM v4 does not differentiate by server location. Two identical pages with identical data transfer produce the same formula result regardless of whether one is hosted in Oslo and the other in Warsaw.

This is a known and deliberate limitation: location-aware carbon intensity would require real-time electricity grid data for every possible server and user location, which is not practically available at the scale carbon tools need to operate. Organisations like Electricity Maps provide this data via API, and some advanced implementations use it — but it is not part of the standard SWDM v4 methodology.

5. Cached Assets Are Not Modelled

SWDM v4 as typically implemented calculates CO₂ for a first uncached visit. But real-world visits include a mix of first-time visitors (full page weight) and returning visitors with some or all assets cached (near-zero weight for cached resources). A site with 70% returning visitors who browse with warm caches will have real per-visit emissions substantially lower than the formula suggests.

The SWDM v4 specification acknowledges this and provides an optional adjustment for returning visitor caching, but most tools — including Carbon Badge in its standard scan — implement the uncached first-visit model because it is the only calculation that does not require knowing your site's returning visitor ratio and cache hit rate. Both of those figures vary by site and are not available to an external scanner.

6. Server-Side Processing Is Not Included

The data centre coefficient (0.055 kWh/GB) represents the energy used by data centre infrastructure per GB transferred — but it does not separately account for the CPU cycles used to generate a dynamically rendered page. A WordPress page rendered from a database query on every request uses more server energy than the same content served from a CDN cache. A server-side rendered React application uses more than a pre-built static HTML file.

The formula treats all GB equally, regardless of how computationally expensive it was to generate that GB on the server side. For static sites served from CDNs, this is a minor gap. For compute-heavy applications, it may meaningfully understate actual server-side emissions.

SWDM v4 vs Other Methodologies

SWDM v4 is not the only framework for calculating digital carbon. It is the most widely adopted for website-level calculations, but two alternatives are worth knowing about:

The OneByte model (used by some earlier tools) applied a single coefficient per byte without segmenting by infrastructure type. It produced different results than SWDM and has largely been superseded. If you see a very old carbon audit citing dramatically different numbers than current tools, it may be using a pre-SWDM methodology.

The GHG Protocol digital emissions accounting framework takes a different approach: rather than modelling per-GB energy, it attempts to allocate actual measured energy consumption from data centres and networks to individual services. This is more accurate for large organisations doing formal corporate carbon accounting, but requires access to data (energy bills, hardware inventories, usage logs) that external tools cannot access. For web developers looking to benchmark and compare pages, SWDM v4's approach is more practical.

CO2.js — maintained by the Green Web Foundation — implements SWDM v4 directly in JavaScript and is the standard programmatic interface for developers who want to integrate carbon calculations into their own tools, CI pipelines, or applications. It is not a competing methodology; it is an implementation of SWDM v4. The measurement guide covers how to use CO2.js in your own code.

What SWDM v5 Might Look Like

The Sustainable Web Design community has published discussion of what future versions might address. Based on the known limitations and community conversations, several changes seem likely as the model evolves:

Device differentiation. The end-user device coefficient (currently 0.080 as a single global average) could be split by device category, allowing tools that know their audience's device mix to apply a more accurate figure. This would require a documented disaggregation of the research behind the current average.

Network type differentiation. A similar split between wired and mobile network coefficients would allow tools that have access to their audience's connection type distribution to apply the more appropriate figure. This data is available from analytics platforms and would be straightforward to use if the methodology formalised its use.

Location-aware carbon intensity. Integrating real-time or average grid carbon intensity by country or region would dramatically improve accuracy for sites with concentrated geographic audiences. The tooling exists (Electricity Maps, Ember Climate country-level data) — the barrier is standardising how it integrates with the SWDM framework.

Returning visitor modelling. A standardised approach to adjusting for cache hit rates — perhaps using an industry average derived from HTTPArchive data on cache headers and return visitor rates — would make the formula's output more representative of real-world per-visit emissions rather than worst-case first-visit emissions.

Updated coefficients. As IEA and Ember Climate publish more recent data, and as network efficiency research matures, the 0.194 and 494 constants will be reviewed. Energy efficiency improvements in data centres and the ongoing decarbonisation of major electricity grids both point toward lower values over time.

The core framework — segmenting by data centre, network, and device; expressing energy consumption per GB; applying a carbon intensity multiplier — is likely to remain stable. The SWDM community has been clear that the framework's value is consistency, and radical restructuring would break comparability with historical measurements.

Practical Takeaways for Developers

After all that methodology, what should you actually do with this knowledge?

First: trust the direction, not just the number. If SWDM v4 says your page emits 0.8g CO₂ and a competitor's page emits 0.2g, the meaningful information is that your page is approximately 4× heavier — not that the exact gram figures are precise to two decimal places. The formula's value is comparative and directional.

Second: the biggest levers are still page weight and green hosting. Despite all the nuances in the methodology, the two variables you can control — how much data you transfer, and whether your host uses renewable energy — are responsible for the vast majority of variation between websites. Obsessing over methodology is less useful than obsessing over image compression and JavaScript bundle size.

Third: the model rewards transparency. Because SWDM v4 is fully open and every constant is published with its source, you can verify any tool's output independently. The formula above is everything you need. Run it in a spreadsheet. Verify that Carbon Badge's result matches your manual calculation. If it does not, the discrepancy is almost certainly in how the page weight was measured — tools differ in how comprehensively they simulate browser resource loading.

For ongoing monitoring of how your score changes with deployments, the context on internet-scale carbon emissions is a useful reminder of why site-level optimisation connects to a larger picture. And if you are looking at how your scores compare to industry benchmarks, the primer on website carbon footprints covers what grades mean in practical terms across different site categories.

The model is imperfect. It is also the best widely-adopted tool we have for making website carbon visible, comparable, and improvable. Use it with clear eyes about what it measures and what it does not, and it will serve you well.