The one-line version
When SCTE-35 is the right answer
An upstream broadcaster is already signalling breaks. Honouring their cues is the job; inventing your own carrier does not change what they send.
An ad server, an SSAI vendor or a partner distributor. They expect SCTE-35 and are not going to build a parser for your ID3 schema.
Rights agreements are written in terms of break types and blackout rules, which are exactly what SCTE-35 descriptors encode.
Encoders, splicers and packagers already speak it. Using anything else means fighting the chain you bought.
Regional blackout signalling has no equivalent in ID3. This is a genuine capability gap, not a preference.
A standard is portable. A bespoke ID3 schema is a migration project every time a component changes.
When ID3 is the right answer
Your encoder, your player. There is no interoperability to preserve, so the constraint SCTE-35 buys you is a cost with no return.
A score change, a chapter marker, a quiz prompt. SCTE-35 has no vocabulary for these, and forcing them into one is worse than using a container built for arbitrary payloads.
Drawing an interactive element at a moment needs the player to receive the event. ID3 arrives as an ordinary media event; SCTE-35 frequently does not arrive at all.
You need a JSON object with five fields. SCTE-35 has nowhere to put it; ID3 carries it without complaint.
ID3 end to end is an afternoon on a chain you control. SCTE-35 is a conversation with whoever runs your encoder.
Until the semantics settle, a container that does not constrain them is the honest choice. Standardise once you know what you are signalling.
What each looks like on the wire
The difference in philosophy shows up immediately. One is a message with agreed fields; the other is a labelled envelope with your data inside it.
#EXT-X-DATERANGE:ID="break-7",
START-DATE="2026-09-07T14:32:10.000Z",
PLANNED-DURATION=30.0,
SCTE35-OUT=0xFC302F...ID3 TXXX frame
description : "overlay"
value : {"type":"sponsor_card","id":"sc_412","dwell":8}Nothing in the second example is wrong. It is simply that no splicer, ad server or partner will ever know what a sponsor_card is, and every consumer of it is a piece of software you have to write and keep alive. That is the entire trade, stated as plainly as we can put it.
Most real chains use both
Framing this as a choice is usually the mistake. The two live at different layers, and a channel of any size ends up wanting both: SCTE-35 where broadcast equipment and commercial partners have to agree on what a break is, ID3 where your own player has to do something visible at a moment nobody else cares about.
A workable split looks like this. Let SCTE-35 carry break signalling — start, duration, type, blackout — because that is the vocabulary your encoder, your packager and any third party already share. Let ID3 carry application events — the sponsor card, the score bug, the interactive prompt — because those have no standard meaning and never will.
And it is worth repeating the answer that most often makes both unnecessary: if the sponsor element is burned into the frame server-side, the viewer receives ordinary video and no timed metadata is required anywhere in the chain. That is the approach described on the server-side ad insertion page, and it is why a good number of the channels we work with never had to resolve this comparison at all. If you do need signalling, start by finding out what your stream already carries — the validator page covers the checks worth running first.
Frequently asked questions
What is the difference between SCTE-35 and ID3 timed metadata?+
They solve overlapping problems from opposite directions. SCTE-35 is a broadcast standard for signalling advertising opportunities — it has a defined message structure, defined break semantics and defined descriptor types, and equipment across the broadcast chain already understands it. ID3 timed metadata is a general-purpose container for arbitrary timed events, borrowed from audio tagging: it will carry whatever you put in it, and nothing downstream knows what your payload means unless you also wrote the thing reading it.
Can I use ID3 for ad breaks instead of SCTE-35?+
Technically yes, and some platforms do. The trade is interoperability for freedom. Nothing in a standard ad chain — a splicer, an ad decision server, a third-party SSAI vendor — will act on your ID3 payload without custom integration, because there is no agreed schema for what an ad break looks like in ID3. If you own both ends of the pipeline, that cost may be zero. If you do not, it is the whole project.
Which one do players support better?+
ID3, on the web and in mobile apps, by a comfortable margin. Browser and app players surface ID3 timed metadata as ordinary media events that JavaScript or native code can listen for. SCTE-35 support in players is patchy and inconsistent — many players ignore cue tags entirely, which is legal, since HLS players are expected to skip tags they do not recognise.
Can a stream carry both?+
Yes, and in practice many do. A common pattern is SCTE-35 for the ad-break signalling that broadcast equipment must honour, and ID3 alongside it for application-level events the player is expected to react to — a scoreboard update, an overlay trigger, a chapter marker. They occupy different layers and do not conflict.
Which should I use for a sponsor overlay?+
Neither, in most cases. If the overlay is burned into the frame server-side, the viewer receives ordinary video and no timed metadata is needed at all — nothing downstream has to be told anything. Timed metadata matters when a client has to do something at a moment: draw an interactive element, update a widget, fire an analytics event.
Is ID3 timed metadata reliable in live streams?+
Reasonably, with two caveats worth knowing. Delivery timing is tied to segment boundaries in the same way everything else in HLS is, so an event can arrive a segment early or late. And some packagers and CDNs strip or reorder metadata they do not recognise, which is exactly the failure mode SCTE-35 also suffers. Test it end to end on your own chain rather than trusting either specification.
Send us your HLS stream URL. We will show you where the SCTE-35 cue is lost.
You get a plain report: which cues are present, whether every break opens and closes, whether the durations agree, and the first hop where the signal disappears. One URL, one working day, and no obligation to buy anything.
Video-technology engineer in Thane, India. Send me one live stream URL and I will run a free test on your own feed. You get my reply within one working day (IST), from the person who builds it, not a sales queue.
Bring us your stream.
Send us one live URL and what you want on it. We will put a demo on your own feed before you commit to anything.