The Global Media Sustainability Framework (GMSF) is a voluntary standard developed by Ad Net Zero and the advertising industry, to help calculate and reduce greenhouse gas emissions from media campaigns.
We have previously provided some general guidance on how this works, and to access this with working examples included, simply CLICK HERE
The GMSF is built upon both carbon-accounting and industry best practices and aims to provide consistent methodologies across Digital, TV, Out-of-Home, Print, Audio, and Cinema. It enables advertisers, publishers and their partners to responsibly offer, plan and buy media with environmental impacts in mind whilst increasing transparency, accuracy, and progress towards a lower-carbon future.
The framework has recently had a very large set of updates. Additionally IAB Europe’s Methodology & Framework Working Group have developed (in partnership with Ad Net Zero) a proposed voluntary specification called carbon.json, designed to enable ad tech vendors to publish a standard JSON file describing its own infrastructure carbon intensity. this proposal is currently a public-feedback draft (v1.0), and IAB Europe intends to address feedback and explore integrating a carbon.json-based methodology into future versions of the GMSF.
This article intends to provide an explainer on the udates to the GMSF from v1.2 to v1.3 and also an introduction to the carbon.json proposal from IAB Europe.
What’s new in GMSF v1.3 for digital?
As per our original explainer, the digital structure is essentially unchanged with three phases, three focus areas and three input types.
What v1.3 does change is how some impacts are treated and how clearly uncertainty and electricity are handled.
Key changes relevant to digital:
- Updated Digital Data Guidance, and a signal beyond ads.txt. Digital guidance and default values have been refreshed, and v1.3 explicitly frames ads.txt as a stop-gap proxy for programmatic emissions, not the end-state – opening the door to more activity-based methods such as carbon.json. Adoption will take time, so ads.txt remains the usable method today.
- Corporate Overhead Emissions (and AI). A new top-down methodology allocates corporate overhead emissions (e.g. sales, marketing, HR, product development) to campaigns based on spend, impressions or effort, after subtracting emissions already counted elsewhere in the GMSF. For digital, this is now the primary route for capturing AI-related emissions which include model training, experimentation and platform-level AI product development, that aren’t tied to specific campaign operations.
- Boundary corrections in Creation. Post-production storage of assets has moved out of the GMSF’s digital boundary and into dedicated production calculators such as AdGreen, alongside the already-excluded asset production step. Creation within the GMSF now focuses on asset manipulation and generation, including DCO and AI-based creative variants.
- Electricity rules: location-based as the baseline. v1.3 codifies that location-based grid emission factors must be used as the minimum in any electricity-related estimate, with market-based claims (renewable tariffs, PPAs, RECs/EACs) only disclosed as an additional, non-netting layer. This keeps campaign estimates comparable regardless of how entities procure renewables, and the same principle underpins carbon.json.
- Data Uncertainty Tiers. Each estimate is now tagged as low (green), medium (amber) or high (red) uncertainty, based on how much of the calculation uses granular data versus higher-level defaults. This makes it easier for buyers and sellers to be transparent about how robust a CO2e figure really is. This aligns naturally with the ‘data hacks’ approach, whereby the more you rely on defaults rather than activity-based data, the higher the uncertainty and now there’s a consistent way to flag it when you share any estimates.
The carbon.json proposal
An important forward-looking development for calculating digital emissions is carbon.json which is a proposed voluntary specification, developed via IAB Europe’s Methodology & Framework Working Group in close partnership with Ad Net Zero.
The concept is of a machine-readable disclosure of infrastructure carbon intensity by digital advertising technology solutions (such as SSPs, DSPs, ad servers & exchanges) to publish a standardised JSON file declaring the carbon intensity of its own infrastructure. The single mandatory metric is location-based gross core emissions intensity, which are expressed as kg CO2e per 1,000 attributable delivered impressions.
Importantly, it is narrower than both a corporate GHG inventory and a full campaign footprint. It’s an infrastructure-intensity input designed to be summed across the systems actually on the delivery path to build a path-level estimate. It deliberately does not measure the full campaign footprint, media production, end-user device emissions, or open-internet infrastructure the reporter doesn’t operate.
Note: JSON (JavaScript Object Notation) is a text-based data interchange format widely used for data exchange in web applications. JSON has become increasingly popular due to its ease of readability and writing by humans as well as machines.
Why it matters for the ads.txt limitations
ads.txt (Authorised Digital Sellers) is a simple, secure, flexible text-file mechanism for publishers to publicly declare the companies authorised to sell their digital inventory. Publishers post the ads.txt file on their root domain (and subdomains as needed). The standard also extends to apps via app-ads.txt.
Each authorised seller account ID is listed as an individual line as it’s a potential path for programmatic transactions. The total number of lines is the figure currently used for the GMSF calculations. The number of ads.txt lines is the canonical proxy for the volume of server activity associated with ads on a domain, and it has worked well as a stop-gap to make programmatic emissions estimable at all.
However, the GMSF itself acknowledges it is imperfect, and it can materially mislead in two opposite scenarios:
Heavy file, light reality: a media owner with a long ads.txt file that throttles activation aggressively will generate lower server activity than the proxy implies.
Lean file, heavy reality: a media owner with a short ads.txt file whose demand graph fans out aggressively after the first hop will generate higher server activity than the proxy implies.
This is exactly the gap the proposed carbon.json approach is designed to close, by replacing a structural proxy with disclosed, activity-based intensity from the systems actually on the path. Also, because carbon.json requires the denominator to include failed bids, lost auctions, duplicate path attempts, idle, reserve and resiliency capacity wherever those support delivered impressions, it captures exactly the demand graph fan-out that an ads.txt line count cannot see. For path-level use, a buyer or calculator sums the published intensity of each disclosing system on the actual path which is a far more accurate picture than lines as paths.
Notable design features:
- Comparable and machine-readable, with one mandatory metric and a provider-neutral JSON Schema.
- Location-based core that keeps market-based claims, offsets, removals and avoided-emissions out of the comparable figure (they can be disclosed separately as non-comparable).
- Data-quality tiers (A–D) and uncertainty buffers, so a disclosure is honest about its own confidence — conceptually aligned with the GMSF’s Data Uncertainty thinking.
- Provider-neutral across deployment archetypes such as owned and leased data centres, colocation, public cloud and edge, without provider-specific schema rules.
- 5% exclusions cap inside the declared boundary, and defined rules for facility overhead (PUE), embodied service lives, allocation and geographic/service-scope labelling.
The public feedback period is open until 19th August 2026. Feedback can be submitted via GitHub Issues (the preferred route, with public-feedback, schema and implementation-question templates) or by email to IAB Europe. The most useful comments identify the affected section or schema field, describe the concern, propose specific wording or schema changes, and explain the expected impact on comparability, feasibility or data quality.
To review the repository and draft go to: github.com/iabeurope-beis/carbon-json
We encourage local ad tech vendors, publishers and agencies to review and consider testing the draft against their own infrastructure and submit feedback. This can help to strengthen the specifications and ensure that Australian operating realities (e.g. our grid emission factors and market structure) are competently reflected before it is published.