Most of ISO/IEC TS 20125-1:2026 is written the way standards are supposed to be written: technology-neutral, so it doesn’t need revising every time a new format ships. Then, in one clause of the Implementation phase, it stops being neutral and names actual codecs, compression levels, and a viewing-hour window for time-shifting network load. We went looking for where the standard gets this specific, what it actually says, and why that specificity is also its biggest liability.
Standards documents avoid naming specific technologies for a good reason. Name a codec in 2026 and by the time the document goes through its next review cycle, something better has usually shipped and the reference reads as dated at best, wrong at worst. So most sustainability guidance stays at the altitude of “use efficient formats” and leaves the specifics to whoever’s implementing it. ISO/IEC TS 20125-1:2026 mostly follows that convention too, until Stage 3: Implementation, where it briefly doesn’t.
Implementation is the third of the standard’s six life cycle phases, and it’s built from five ecopractices: collecting only the data items a service strictly needs, limiting and optimising processing, selecting scalable and appropriate technologies, integrating usage and efficiency monitoring, and favouring consolidation and reuse of existing service elements. Four of those read like most of the rest of the standard, principles stated generally enough to survive a decade of tooling changes. The second one, “limit and optimise processing,” doesn’t.
Where the standard names names
The core requirement in that ecopractice is unremarkable on its own: a digital service provider shall implement data compression techniques to reduce data transfer and processing overhead, and should use video, audio, and image formats with efficient compression, adapted to the content and the context they’re viewed or heard in. That’s the kind of technology-neutral phrasing you’d expect.
What follows it isn’t a requirement at all. It’s an example, explicitly labelled as one, attached to that “should” to illustrate what “efficient” could mean in practice. For images, it points to WebP, AVIF, or JPEG XL, with a specific compression level, 82 for WebP or 64 for AVIF. For video, it points to VP9, HEVC, or AV1, sized to the device: 720p for smartphones, 1080p for tablets and PCs, 1440p for TVs. For audio, it lists Opus, AAC, and several of AAC’s variants alongside Dolby’s E-AC-3 and AC-4, and adds a rule of thumb instead of a codec: keep the file’s megabytes-to-minutes ratio at 1 or under, whichever codec you’re using.
That’s an unusual amount of engineering detail to find inside an ISO document, and it’s worth noticing what the standard did to protect itself while including it. Every one of those lists ends the same way: “or a higher performance format” for images, “or a higher performance video codec” for the video list, “or a higher performance audio codec” for audio. The committee named today’s best-known options and then explicitly told the reader not to stop there. That’s the standard building its own expiry date into the text, which is a more honest move than most best-practice content manages.
A second kind of example: time-shifting for reasons that aren’t all carbon
The same “should” list carries a second example worth reading closely, because it’s more layered than a single grid-carbon story. It frames time-shifting as a response to three separate outside constraints, not one. On energy, it recommends avoiding asynchronous computing or data transfers during the times of day when electricity generation is most carbon-intensive, for operations that can tolerate the delay. On computing infrastructure, it recommends delaying non-urgent calculations and updates when compute availability is low, specifically to avoid provisioning new hardware to cover the peak. On telecom networks, it recommends shifting heavy operations away from a defined evening window, 7pm to 11pm local time.
Only the first of those three is what people usually mean by carbon-aware scheduling. The standard is explicit about the reasoning behind the second: delaying non-urgent work when compute availability is low, so a provider doesn’t have to buy new equipment to cover a temporary peak. It’s not explicit about why the telecom window is 7pm to 11pm specifically, it states the recommendation without a stated cause. Read next to the compute example, a shared-network-congestion reading is the natural one, evening hours are widely known consumer usage peaks, but that’s our inference, not something the standard says outright. Either way, both are about not straining infrastructure that’s shared with everyone else on it, which is a related but distinct kind of “outside constraint” from grid carbon intensity, worth keeping separate when you’re deciding what to build against.
Why this shouldn’t become your codec policy
None of the specifics above are things TS 20125 requires. They sit under a “should,” inside a labelled example, two steps removed from the closest thing to an obligation in that clause. That distance is deliberate, and it should stay that way when this shows up in your own engineering guidelines.
Codec recommendations age faster than almost anything else in this space. AVIF and JPEG XL barely existed in mainstream tooling a few years before this standard was drafted. AV1 encoding is still uneven across hardware. HEVC carries licensing complications that have nothing to do with efficiency and everything to do with why some teams avoid it regardless of how it performs. A document published once and revised on an ISO review cycle cannot keep pace with that, and the standard’s own “or a higher performance format” clause is effectively an admission of that fact. Treat the named codecs as evidence of the standard’s intent, favour formats that measurably outperform their predecessors and revisit that choice, not as a fixed answer you can paste into an engineering wiki and stop thinking about.
That’s also the more useful lesson buried in this clause than the codec list itself. The same “should” list that hands you the codec example also recommends creating performance benchmarks to track progress toward processing goals, and regularly reviewing algorithms and data structures rather than optimising them once. Zoom out one ecopractice, to “collect strictly needed items,” and there’s an outright requirement to run ecoefficiency assessments regularly, with a should-level recommendation layered on top to fix that into a defined schedule, quarterly, say, or after every major deployment. Read together, the standard’s actual expectation for Stage 3 isn’t “use AVIF.” It’s “know what’s currently efficient and keep checking,” which the codec list only ever illustrated once, at the moment it was drafted. An organization that adopts the 2026 codec list and calls it done has missed the point of the clause it came from. An organization that treats “what’s currently the most efficient format for this content, on this device class” as a question worth asking on a recurring basis has understood it, and that habit is worth more than any single format choice, this year or the next.
There’s a way to read all this as a flaw in how the standard is assembled, another inconvenience layered onto an already long conformance checklist. That reading doesn’t hold up. A standard that could name a fixed set of formats and consider the subject closed would be describing a version of this work that doesn’t exist, one where the efficient choice holds still long enough to be settled once and left alone. The actual tension, between guidance meant to stay valid for a decade and a subject matter that turns over every year or two, isn’t only a cost to manage. It’s close to what makes this field difficult, and for the kind of engineer who’d rather keep earning the right answer than inherit a fixed one, that’s also what makes it worth doing.
If you’re working through what TS 20125 conformance actually requires phase by phase, or want a second opinion on how your current stack holds up against it, get in touch. And if your organization is further along than a single conformance declaration and wants that discipline verified rather than self-reported, that’s what GSP™ certifies.
