Methodology

How emissions.dev calculates carbon emissions.

Overview

All emissions.dev calculations are:

• GHG Protocol compliant — Corporate Value Chain (Scope 3) Standard
• Expressed in CO₂e — using IPCC Sixth Assessment Report Global Warming Potential over 100 years (AR6 GWP100)
• Fully traceable — every response includes a source_trail naming the exact emission factor, source dataset, year, and region
• Well-to-Wheel by default — lifecycle emissions including fuel production (WTT) and combustion (TTW)

Standards & Frameworks

Calculation Fundamentals

Global Warming Potential (GWP100)

All emission factors are converted to CO₂-equivalent (CO₂e) using IPCC Sixth Assessment Report (AR6) GWP100 values. This is the most current IPCC assessment and is required by major reporting frameworks.

Every API response includes a co2e_calculation_method field confirming ipcc_ar6_gwp100 was used.

Well-to-Wheel (WTW) Lifecycle

By default, all APIs calculate total lifecycle emissions. The response includes a lifecycle_breakdown splitting this into two stages:

Total Emissions = WTT + TTW

For the Electricity API, WTT represents upstream fuel emissions from power generation and is mapped to Scope 3 Category 3 (Fuel- and energy-related activities). WTT can be disabled with include_wtt=false when only Scope 2 is needed.

Data Sources & Quality

Emission Factor Sources

We use only data published by government agencies, international standards bodies, and peer-reviewed academic institutions. We do not create our own emission factors or use proprietary models.

How We Validate Data

Each emission factor in our database is verified against the original source publication:

1. Source verification — We confirm the factor appears in the named dataset, edition, and table. Every factor is traceable to a specific published document.
2. Unit normalisation — Factors are converted to a consistent unit (kg CO₂e per activity unit) with the original units documented in the source trail.
3. AR version check — We verify which IPCC Assessment Report the source used for GWP values. Where sources use older AR values (AR4, AR5), we note this in the source trail. DEFRA 2025 and GLEC v3.1 both use AR6.
4. Cross-reference — Where multiple sources cover the same activity (e.g. UK electricity grid intensity from both Ember and DEFRA), we compare values to identify discrepancies.
5. Annual review — When sources publish updated editions, we review changes and update our database. See Data Updates below.

Data Quality Tiers

Following the GLEC Framework's tiered approach:

Our API uses Tier 1 and Tier 2 data. You can improve accuracy towards Tier 3 by providing more specific parameters (vehicle type, fuel source, exact weights, specific locations).

Source Trail & Transparency

Every API response includes a source_trail array — the full audit trail of emission factors used in the calculation. This is included by default in all responses at no extra cost.

What the Source Trail Contains

Each entry in the source_trail array includes:

Example Source Trail

{
  "source_trail": [
    {
      "data_category": "emission_factor",
      "name": "Articulated HGV - Diesel",
      "source": "GLEC",
      "source_dataset": "Default fuel efficiency and GHG emission intensity values v3.1",
      "year": "2025",
      "region": "GLOBAL"
    }
  ]
}

Why This Matters

The source trail exists so that:

• Auditors can verify exactly which factor was applied and trace it back to the original publication
• Developers can store the trail alongside calculated emissions for future reference
• Compliance teams can demonstrate methodology transparency for GHG Protocol, CSRD, or other reporting requirements
• Reproducibility is guaranteed — the same inputs with the same factor year will produce the same outputs

GHG Protocol Scope Mapping

Every API response includes a ghg_protocol_scopes object that pre-categorises emissions into the correct GHG Protocol scope and category. You don't need to map these yourself.

Scope & Category Coverage

Dual Perspective (Freight)

The Freight API provides scope mapping from two perspectives, since the same shipment falls under different scopes depending on your role:

• freight_buyer — If you're purchasing transport services, the total emissions are your Scope 3 Category 4 (or 9 for outbound)
• asset_owner — If you operate the vehicles, TTW is your Scope 1 and WTT is your Scope 3 Category 3

Scope 2: Location vs Market-Based

The Electricity API supports both GHG Protocol Scope 2 methods:

• Location-based — Uses the average grid intensity for your region. Calculated automatically from Ember/EPA data.
• Market-based — Uses supplier-specific factors or residual mix. Pass your supplier's factor via the market_based_factor parameter. Returns null when no supplier factor is provided, with a note explaining why.

API-Specific Methodology

Freight API

Formula:

Emissions (kg CO₂e) = Distance (km) × Weight (tonnes) × Emission Factor (gCO₂e/tonne-km) / 1000

Emission factors by mode:

Distance calculation:

• Road: OSRM road network routing (real driving distances)
• Sea: Maritime shipping lane distances (Suez, Panama, Cape routes)
• Air: Great circle distance
• Rail: Direct distance estimation

Vehicle types: small (under 3.5t), medium (3.5–7.5t), large (7.5–17t), articulated (over 17t), average (fleet default).

Fuel sources: diesel, petrol, electric, hybrid, hvo, cng, lng, hydrogen.

Service types: shared, dedicated, ftl (full truckload), ltl (less-than truckload).

Travel API

Flights:

Flight emissions are calculated using DEFRA 2025 factors with ICAO distance data. The calculation includes:

1. Base emissions — Fuel burn per passenger-km, varying by haul type (domestic, short-haul, long-haul)
2. Radiative forcing — A multiplier to account for the increased warming effect of emissions at high altitude. The DEFRA factors include a radiative forcing multiplier.
3. Cabin class allocation — Seat area weighting, reflecting the greater floor space occupied by premium cabins

Other modes:

The Travel API also covers car, taxi, bus, and ferry journeys. For car travel, emissions are based on vehicle size, powertrain type, and distance. Electric vehicle emissions use grid intensity data from the Electricity API's sources.

Hotel API

Hotel emissions use per-room-night factors that vary by country based on:

• Grid carbon intensity — the primary driver, as electricity powers most hotel operations
• Climate zone — heating and cooling energy demand
• Hotel energy efficiency — regional building standards and practices
• Water heating — energy for hot water supply

Data sources: DEFRA 2025 and the Cornell Hotel Sustainability Benchmarking (CHSB) Index, which provides energy consumption benchmarks for 60+ countries.

The response includes a factor object showing the per-room-night emission factor used, whether it's a country-specific value or a regional estimate, and the geographic region it applies to.

Electricity API

Formula:

Emissions (kg CO₂e) = Consumption (kWh) × Grid Intensity (gCO₂e/kWh) / 1000

Grid intensity resolution (priority order):

The response includes source field indicating which resolution was used (cloud_region, us_state, or country), and the grid_intensity value applied.

Optional adjustments:

• include_wtt=true (default) — Adds upstream fuel production emissions (Scope 3 Category 3), typically adding ~18% to the total
• include_td_losses=true — Adds transmission and distribution losses (~8%), accounting for electricity lost between power station and point of use

Fuel Combustion API

Supported fuel types:

Each fuel type accepts the units most natural for that fuel (e.g. kWh for gas, litres for diesel, kg for solid fuels).

The response includes a gas-by-gas breakdown showing individual CO₂, CH₄, and N₂O contributions, plus the combined CO₂e total. For biofuels, the response separates biogenic CO₂ (outside Scope 1) from fossil emissions, following GHG Protocol guidance.

GHG Protocol mapping: Direct combustion emissions are mapped to Scope 1. When include_wtt=true (default), upstream fuel production emissions are separately reported as Scope 3 Category 3.

Region & Year Fallback Logic

When specific data isn't available for a requested region or time period, the API uses transparent fallback logic rather than returning an error. Fallbacks are always flagged in the response.

Electricity API

The Electricity API uses the most specific grid intensity available. If a US state is requested but not in EPA eGRID, it falls back to the US national average from Ember. If a country isn't in Ember's dataset, no fallback is applied and an error is returned — we don't guess grid intensities.

Hotel API

When a country-specific hotel factor isn't available (e.g. UAE), the API uses a regional average (e.g. Middle East) from the Cornell CHSB Index. When this happens:

• The factor.is_estimate field is set to true
• A notices array includes a message explaining the fallback: "Using Middle East regional average for United Arab Emirates. Country-specific data not available."

This ensures you always know when an estimate is being used versus a precise country factor.

Freight API

The Freight API uses GLEC global default factors (Tier 1) when region-specific factors aren't available. These are internationally accepted defaults specifically designed for this purpose. You can improve accuracy by providing more specific parameters (vehicle type, fuel source).

Year Handling

All APIs use the most recent factor year available from each source. The exact year used is recorded in the source_trail. We do not extrapolate or project factors into future years.

Data Updates

Current Factor Versions

How Updates Work

When a source publishes a new edition:

1. We review the changes — comparing new factors against the previous edition to identify material differences
2. We update our database — new factors are loaded and validated against the source publication
3. API responses use the latest factors — by default, all API calls use the most current factors available
4. The source trail reflects the update — the year field in the source trail will show the new factor year

Reproducibility: If you need to reproduce calculations from a previous reporting period, store the API response (or at minimum the source_trail) at the time of calculation. This documents exactly which factors were used. We recommend making all calculations for a given reporting year within the same period to ensure factor version consistency.

Planned Updates

• DEFRA 2026 — Expected June 2026. Will be integrated within one week of publication.
• EPA eGRID 2024 — Expected late 2026.
• GLEC Framework — Monitoring for v3.2 or subsequent revisions.