Is a stream broken if it plays fine in VLC but not in a browser?

Not necessarily broken, but incomplete for web delivery. VLC does not enforce CORS or mixed-content rules the way browsers do, so a stream missing Access-Control-Allow-Origin or served over plain HTTP from an HTTPS page will fail in-browser while working perfectly in a desktop player.

How can I tell if a "live" stream is actually stalled?

Fetch the manifest or playlist twice several seconds apart. If the segment list, media sequence number, or timeline is byte-for-byte identical both times, the origin has stopped publishing new segments even though the URL still resolves.

Do I need different tools for HLS versus DASH versus IPTV playlists?

The entry-point check (does the URL fetch, what content type comes back) is identical across formats, but the deeper validation differs: HLS and DASH each have their own tag/attribute rules, and IPTV M3U playlists need channel-URL and EPG-matching checks that neither HLS nor DASH require.

What is the single most common reason a stream URL fails silently?

A redirect or CORS gap that a browser hides during casual testing but a dedicated player does not tolerate. Always check the raw HTTP response with curl before trusting that "it opened in my browser" means the URL is production-ready.

How to Test a Stream URL (HLS, DASH, or IPTV)

To test a stream URL, first confirm the URL itself is reachable and returns the right content type over HTTP, then identify whether it is HLS, DASH, or an IPTV playlist and run the checks specific to that format. A URL that "loads in a browser" is not proof of anything, since browsers hide redirects, CORS failures, and stale caching that break other players.

Every format eventually reduces to the same three layers: does the entry-point document fetch correctly, does it describe media that actually exists at the URLs it references, and does a real player start and hold playback. This guide walks that path for any format and links to the deeper guide or tool for whichever one you are testing.

If you already know the format, jump straight to the linked format guide. If you are troubleshooting a stream someone handed you with no context, start at the top here and let the response headers tell you what you are dealing with.

What is the very first thing to check on any stream URL?

Fetch the URL with curl -I (or a full GET if HEAD is not supported, since some origins reject HEAD on media endpoints) and read the HTTP status code before anything else. A 200 with a body is the minimum bar; 301/302 redirects are common and not inherently wrong, but note where they land, since some players will not follow a redirect chain for every subsequent segment request even when they follow it for the initial manifest.

Check Content-Type next: application/vnd.apple.mpegurl or audio/mpegurl signals HLS, application/dash+xml signals DASH, audio/x-mpegurl or a plain .m3u/.m3u8 with no DASH XML signals an IPTV playlist. A generic application/octet-stream or text/plain does not rule anything out; open the body and look for #EXTM3U (HLS or IPTV playlist) versus an XML declaration with <MPD (DASH).

How do I tell HLS, DASH, and an IPTV M3U playlist apart?

HLS and IPTV playlists both use the M3U syntax and both start with #EXTM3U, which is why they are easy to confuse. A genuine HLS media or master playlist contains HLS-specific tags such as #EXT-X-VERSION, #EXT-X-STREAM-INF (master playlist, listing variant bandwidths and resolutions), or #EXTINF entries pointing at .ts/.m4s segments with tags like #EXT-X-TARGETDURATION.

An IPTV channel playlist also starts with #EXTM3U but its #EXTINF lines carry channel metadata (tvg-id, tvg-name, group-title) and point at whole live channel stream URLs rather than short media segments; there is no #EXT-X-STREAM-INF variant structure. DASH is unambiguous because it is XML, not M3U, and its root element is <MPD>.

What do I check once I know it is HLS?

For a master playlist, confirm every #EXT-X-STREAM-INF variant URL resolves and that BANDWIDTH values are realistic for the resolution listed. For a media playlist, confirm #EXT-X-TARGETDURATION is not smaller than the actual duration of the #EXTINF segments it declares, check whether #EXT-X-PLAYLIST-TYPE is VOD or absent/EVENT for live, and for live playlists confirm the media sequence advances on repeated fetches rather than staying frozen. See the dedicated HLS testing guide for the full walkthrough.

What do I check once I know it is DASH?

Confirm the MPD is well-formed XML, that type is set correctly for live versus VOD, and that the segment addressing (SegmentTemplate, SegmentList, or SegmentBase) resolves to real, fetchable segment URLs. Live DASH adds clock-sync requirements via UTCTiming that VOD does not need. See the dedicated MPD validation guide and the live clock-drift guide for the deeper detail.

What do I check once I know it is an IPTV M3U playlist?

Check that every channel entry's stream URL actually resolves rather than trusting the playlist blindly, since dead channel URLs are the single most common IPTV complaint. Check tvg-id values against a companion XMLTV guide if one is supplied, since a mismatched tvg-id silently breaks EPG data for that channel even though the stream itself plays fine.

How do I verify a stream actually plays, not just that the manifest is valid?

A manifest or playlist can be entirely correct on paper and still fail in a real player because of CORS (missing Access-Control-Allow-Origin on cross-origin segment requests), mixed content (an HTTPS page trying to load an HTTP stream, which browsers block), or a codec the target player cannot decode even though the container is fine. Load the URL in an actual player, not just a validator, before calling a stream "tested".

For live streams specifically, fetch the manifest or playlist twice a few seconds apart and confirm it actually updates (new segments appear, sequence numbers advance); a "live" stream serving an identical response on every refresh is either stalled at the origin or being over-aggressively cached by a CDN.

What HTTP-layer problems break streams regardless of format?

Byte-range requests matter for any format using SegmentBase-style single-file addressing or partial fetches; confirm the origin returns 206 Partial Content with a correct Content-Range when a Range header is sent, since some misconfigured static hosts ignore Range and return the full file, which desyncs playback. Caching headers matter most for live: a manifest or playlist cached for minutes at the CDN edge means every viewer sees a stale live position no matter how fresh the origin actually is.

Run it yourself

Free, no sign-up, and every finding links to an explainer.

HLS analyzer →DASH validator →M3U checker →EPG checker →EPG matcher →

Frequently asked questions

Is a stream broken if it plays fine in VLC but not in a browser?: Not necessarily broken, but incomplete for web delivery. VLC does not enforce CORS or mixed-content rules the way browsers do, so a stream missing Access-Control-Allow-Origin or served over plain HTTP from an HTTPS page will fail in-browser while working perfectly in a desktop player.
How can I tell if a "live" stream is actually stalled?: Fetch the manifest or playlist twice several seconds apart. If the segment list, media sequence number, or timeline is byte-for-byte identical both times, the origin has stopped publishing new segments even though the URL still resolves.
Do I need different tools for HLS versus DASH versus IPTV playlists?: The entry-point check (does the URL fetch, what content type comes back) is identical across formats, but the deeper validation differs: HLS and DASH each have their own tag/attribute rules, and IPTV M3U playlists need channel-URL and EPG-matching checks that neither HLS nor DASH require.
What is the single most common reason a stream URL fails silently?: A redirect or CORS gap that a browser hides during casual testing but a dedicated player does not tolerate. Always check the raw HTTP response with curl before trusting that "it opened in my browser" means the URL is production-ready.