Different browsers do not use the same HLS path
Safari often benefits from stronger native HLS handling, while Chromium browsers frequently rely on hls.js plus Media Source Extensions. That alone can change request timing and visible failure shape.
Policy conditions can diverge
Autoplay rules, CORS interpretation, certificate handling, mixed-content rejection, and embedded-page context can all vary enough to change the outcome between browsers.
Codec and packaging tolerance still matter
Some streams are only barely valid. One browser may tolerate messy timestamps or segment boundaries that another browser exposes more aggressively. That does not make the failing browser irrational.
Use the split as evidence
When one browser passes and another fails, compare where the failure happens. Is the manifest unreadable, the media path blocked, autoplay denied, or decode failing later? That comparison is useful. Generic browser blame is not.
Test both browsers with the same sequence
Run the same URL through the same checks in both browsers: manifest readability, child-resource access, playback attach, and final media behavior. If you change the method, your comparison becomes worthless.
How m3u8play.net helps
Use the site as a consistent control surface. If both browsers classify the manifest the same way but diverge later, the difference probably lives in playback stack, policy, or media behavior rather than in the top URL itself.