Earlier in 2026, at the Green Web Foundation we began investigating how we might expand support in carbon.txt to work with various sustainability labels. One of the more promising ones that caught our eye was Germany’s Blue Angel for Software – the first ever sustainability for label for software. In this post Director of Technology and Policy Chris Adams shares some of the key findings, and thoughts on where web-first, certification of digital products and services might go in future.
Starting out – what is the Blue Angel label in the first place?
Since the late 1970’s, the German government has funded the existence of an ecolabel called the Blue Angel label, used to identify environmentally friendly goods and services.
The Blue Angel label now covers more than 70,000 products, across different more than 100 types of product, from more than 1800 companies.
Relatively recently, two new extensions of the scheme, to cover datacentres and software were developed – the Blue Angel for Resources and Energy-Efficient Software Products (DE-UZ 215) and the Blue Angel for Datacentres (DE-UZ 228) – itself a consolidation of two prior schemes, the Blue Angel for “Energy Efficient Data Center Operation” (DE-UZ-161) form 2012 and the Blue Angel for “Climate Friendly Colocation Data Centers” (DE-UZ214) from 2020.
Our focus for carbon.txt is supporting these two, relatively new schemes – Blue Angel for Resources and Energy-Efficient Software Products (DE-UZ 215), and Blue Angel for Datacentres (DE-UZ 228), and to do this, we need to understand what claims each label makes about products or services that are awarded the label.
Understanding Blue Angel for Resources and Energy-Efficient Software Products (DE-UZ 215)
The first label scheme is specifically aimed at identifying software that demonstrates characteristics we might associate with environmentally friendliness. While the spec is very detailed, there are three high level sets of claims – that it is energy and data efficient, is its backwards compatible with guaranteed updates, and it is free of advertising and tracking.
To earn this label, these properties need to be demonstrated in working software under conditions representative of real world use. In addition, the steps taken to test the software, and was well as how much energy data it uses to carry out common tasks need to be published, and crucially maintain or improve this efficiency over the life time of the label being issued. The label can be issued to open source software as well as proprietary software, and the Blue Angel website lists which products are available:
Understanding Blue Angel For Datacentres (DE-UZ-228)
While the DE-UZ 215 label above covers software, it does not directly refer to datacentres where software is often run, nor the measures that datacentre operators can take to make them more environmentally friendly. Here the Blue Angel For Datacentres (DE-UZ-228) applies.
With this label the claims are mainly about delivering three main benefits for datacentres that are energy efficient, that save resources, and have transparent interfaces.
To earn this label, datacentres need to undergo audit, which includes agreeing to publishing certain standardised metrics related to energy use, water use, and describe how the datacentre operates under real world conditions. Like the software that earns the label, the datacentres are listed on the Blue Angel website as well.
Identifying where to support these labels with carbon.txt
Our vision of carbon.txt at the Green Web Foundation is about two key ideas:
- Machine-readable discovery of sustainability data and claims
- Access to underlying data for independent validation and verification
On the face of it, these are good fits for the two Blue Angel label schemes because they both rely on publishing at least some data that actively demonstrates the underlying claims. For datacentres, it’s about publishing numbers that represent real world performance, rather than an idealised perfect world scenario. For software, how the software is tested, as well as what the software does is published – this means it’s possible to independently verify it, and monitor it.
Why would this be helpful for the label?
This is all well and good, but why would actually be useful for the Blue Angel in the first place? What benefits would this deliver to make it worth adopting? We identified 4 ways we thought it might help:
- Increase the reach of the label – We thought this would make referring to the label in third-party sites and services easier, increasing its reach. Just like how domains and providers with carbon.txt files look different in our own Green Web Directory, and Green Web checks, other software consuming them could do the same.
- Increase the trust over the lifetime of the label award – by linking out to demonstrations of the behaviour that earned the product the label in the first place.
- Increase visibility of compliance with label criteria – by making continuous monitoring possible. We could automate the validation and verification steps of behaviour laid out as conditions of being awarded the Blue Angel label, so it can be run on a schedule, and with notifications sent to staff when conditions are no longer met.
- Increased successful submissions for the label – there is a dedicated role for auditors of the Blue Angel labelling schemes, and while some of these steps have to be carried out manually, some can be automated. The same automated validators that confirm compliance above, could also be used to surface conformance issues early before external review, like a “pre-flight check” before submission.
For space reasons in this post, we’ll cover the just the DE-UTZ-215 label that covers software in more detail, to give an idea of how we thought it might work when investigating. We’ll conclude with a few notes about the DE-UTZ-228 label for datacentres when concluding.
What support for a blue angel for software might look like with carbon.txt
To start off with, one reason we were looking into DE-UTZ-215 Blue Angel for Software label in the first place was how we saw it being used at a conference in late 2025 called Ecocompute.
The claim
There we saw the CEO of NextCloud – a company making a open source office product with the same name – talking about the “Green Gates” they had introduced into the way they build digital products, after earning the Blue Angel label. In the presentation, the speaker spoke about how the Blue Angel label required efficiency to be maintained or improved over the lifecycle of the product:
The independent verification
When looking through the published testing documentation for the software products awarded the Blue Angel, we found that five of the six products awarded the label were set up with tests that:
- are expressed as code
- can be run on an automated basis
- are run regularly as part of a continuous integration suite
- are run using freely available open source software, the Green Metrics tool from Green Coding Solutions
Of these five awarded products, four are open source products. It’s common for open source projects to also have the results of the testing runs in the public domain. If you know where to look, you can find them to independently verify what a CEO is showing off on stage, long after the conference is over.
For Nextcloud, the software is open source, so you can see their source code repository if you want – but these efficiency checks are run in a different source code repository
So you can see these test results yourself, and you can independently verify that the product really is keeping to its efficiency goals, and keeping in that 10% threshold required by the label. You can see one of the charts below, on a site published by the makers of the open source software, Green Coding Solutions:
Testing out if we can pull out just the info we need to see if the software still meets the label
So far we’ve seen that there is information that has to be to published as a condition of getting a sustainability label, and there that it’s structured in a way that lets you build charts.
However, it’s also clear that this is a pretty intimidating interface. As an experiment, we looked into seeing if was possible to fetch just the info we need to show a simplified pass / fail check, for each of the main uses of Nextcloud.
The tests for the Nextcloud cover representative use of written in a number of usage scenario files- usage_scenario_video for video calling, usage_scenario_calendar for managing calendars, usage_scenario_text – for a notes tool and so on. We created a small program that could be run on the command line, to check this gmt-blue-angel-utz-215-energy-checker, where we passed in the location of energy tracking repository, and it would return some simplified info as either text, or as JSON.
The code is open source, but for convenience you can see the output below – when we check the same repo that was being checked yielding the intimidating charts:
$ check-energy --uri https://github.com/green-coding-solutions/nextcloud-gmt
Scenario Baseline(Wh) Recorded(Wh) Var Status
--------------------------------------------------------------------
usage_scenario_video 0.65 0.65 +0.4% PASS
usage_scenario_calendar 0.07 0.07 -1.0% PASS
usage_scenario_text 0.48 0.47 -2.3% PASS
usage_scenario_talk 0.25 0.26 +2.2% PASS
usage_scenario_files 0.11 0.11 +3.4% PASS
usage_scenario_contacts 0.07 0.06 -7.7% PASS
All Blue Angel energy metrics within expected threshold.What does this tell us so far?
One of the key lessons learned is that where you have
- testing for sustainability labels like the Blue Angel software
- a requirement to publish the information about how it was tested
- open source testing tooling or (at least available to run with open interfaces)
Then it becomes possible to independently verify claims about a product, and do so on a schedule, whenever code changes.
This means we can move from certification for products based on annual testing to one based on continuous validation.
This won’t be able to independently verify everything about a piece of software that earned it a sustainability label, and this was an experiment was mainly concerned with starting out with a single metric to track.
An example of supporting Blue Angel for software in carbon.txt
Earlier this month we started a consultation about adding support for certification schemes in carbon.txt.
Hopefully it gives idea of what this might look like, to make it possible to discover when software products from an organisation have met certification standards, and then how to independently verify the claims.
Following the proposed syntax in the post we might have something like this in a file:
version="0.6"
last_updated=2026-06-27
[org]
certification_schemes = [
{
name="blue-angel-de-utz-215",
url="https://www.blauer-engel.de/en/productworld/software"
}
]
disclosures = [
{
doc_type="web-page",
url="https://www.blauer-engel.de/en/products/nextcloud-server",
title="Blue Angel label award for Nextcloud Server" ,
certification_scheme="blue-angel-de-utz-215"
},
{
doc_type="other",
url="https://github.com/green-coding-solutions/nextcloud-gmt”
title="Blue Angel label energy efficiency verification",
certification_scheme="blue-angel-de-utz-215"
},
]
We would add this new checking behaviour as a plugin to the existing open source carbon.txt validator, to introduce new functionality.
However, one of the reasons we were able to carry out the research is also one of the reasons we’re sharing this post before building this out more of this kind of functionality.
There are currently a relatively small number of software products that carry the Blue Angel label. We think this kind of discovery and continual validation would be useful addition to software certification schemes, but we also want to but we’re not sure where the demand is, and how much there is.
If this does seem interesting to you, though we’d love to hear from you – let us know if this is a useful direction for carbon.txt, and if this makes certification schemes like the Blue Angel label more compelling to you.
Onwards!
