iiPTV browser compatibility has three separate parts: importing a playlist, accessing its media and decoding that media on your device. iiPTV can read an entry even when the stream behind it cannot play. This browser compatibility page states current implementation boundaries and recorded tests so you can choose a suitable source without treating a filename as a playback guarantee.
Supported formats for playlist input
M3U files and HTTPS playlist URLs
iiPTV accepts local .m3u, .m3u8 and .txt text files, or a direct HTTPS playlist URL. Files in these supported formats are read locally in your browser. URL import requests the source host directly. A provider homepage, GitHub preview or login page is not a raw playlist response, even if its address mentions M3U.
A channel list contains media addresses and can include names or group information. iiPTV uses these to present searchable entries and group filters. Those metadata fields organize the interface; they do not authorize access or establish codec support for a stream. The M3U guide explains a small complete example.
Supported formats, size limits and relative addresses
The current import limits are 5 MiB and 10,000 entries. These boundaries protect the browser workflow from unusually large inputs. Use a smaller documented list when needed, and preserve the relationship between each entry's metadata and its media URL.
A remote list can resolve relative addresses against its original URL. A local file cannot recover that web base automatically. An isolated HLS manifest with relative segments should therefore be opened using its original manifest URL. Renaming a file or copying only the first manifest does not collect its downstream resources.
Requirements for stream compatibility
Reachable HTTPS sources
iiPTV requires HTTPS source addresses for remote imports and media playback. Stream compatibility requires every referenced resource to be reachable from your device. An expired token, unavailable host or provider access rule can stop playback independently of browser support. Changing http to https only helps if the host actually serves the resource securely.
iiPTV does not proxy a stream or rewrite its addresses through a playback server. Your network connects directly to the source. That design makes the publisher's current access conditions part of iiPTV browser compatibility; it does not bypass them or hide your connection from the source host.
Stream compatibility, cross-origin access and HLS dependencies
Browser-readable responses need appropriate permissions from their hosts. With hls.js, that can include manifests, rendition lists, segments and required keys. A first manifest loading successfully does not establish access to the entire stream. The hls.js documentation describes these resource requirements.
Native browser support can have different access behavior. iiPTV does not add provider-specific headers or change CORS policy. If the list cannot be read at all, use playlist loading help; if entries appear but media fails, use playback help.
Codec support and a playback action
iiPTV attempts HLS through native browser support or hls.js when its capability check succeeds. Other compatible media, including MP4, uses the browser's video element. Codec support still depends on the browser, operating system, device decoders and encoded audio and video.
A container name or .m3u8 extension is not a universal codec promise. Press Play if automatic playback is paused. Where a publisher offers an authorized compatible rendition, that may provide a useful comparison; iiPTV does not transcode unsupported media or expose a manual quality selector.
Recorded browser compatibility tests
The following iiPTV browser compatibility record is dated 2026-10-14. Playback tests used Google Chrome 155.0.8059.40 on macOS, with controlled demo sources bundled with the website. These stream compatibility results describe tested samples rather than every third-party source.
Browser and environment | Sample or workflow | Recorded result |
|---|---|---|
Google Chrome 155.0.8059.40 on macOS | Bundled 8-second MP4 demo, H.264 video and AAC audio | Passed |
Google Chrome 155.0.8059.40 on macOS | Same-origin HLS demo through hls.js and Media Source Extensions (MSE) | Passed |
The same Chrome at a 390px viewport | Responsive layout in a narrow desktop-browser viewport | Checked; not a physical mobile-device test |
Safari on macOS | Native HLS playback path | Implemented; not tested |
Safari on iOS | Native HLS playback path | Implemented; not tested on an iPhone or iPad |
Firefox | Browser playback | Not tested |
Microsoft Edge | Browser playback | Not tested |
Android devices | Mobile browser playback | Not tested on a physical device |
The 390px check uses the same desktop Chrome with a narrow viewport. It checks layout, not an iPhone or Android device's decoder, touch behavior or power constraints. Native HLS paths for Safari are implemented, but neither macOS Safari nor iOS playback has a recorded pass. Firefox and Edge have not been tested.
The MP4 and HLS results demonstrate that playback advanced for those controlled sources. They do not establish codec support for other encodings or guarantee provider authentication, cross-origin access or live channel availability. When comparing iiPTV browser compatibility in your environment, test the demo first and then one authorized source.
Workflows outside current browser support
iiPTV is a player for sources you supply. It does not include a channel package, sell IPTV subscriptions or unlock paid programming. This version does not implement Xtream login, DRM licensing, an EPG programme guide, catch-up television or provider account synchronization.
RTMP, RTSP, UDP and local filesystem media playback are outside the supported web workflow. iiPTV does not provide a server proxy, transcoding service or playlist hosting. Parsed entries and the selected channel are cached in this browser for your next visit. Use Clear or clear website storage to remove them; this cache does not provide an account library or cross-device sync.
A native player can therefore behave differently with the same playlist. Different decoder sets and request methods can explain that difference without proving a defect in either application. Choose the publisher's supported method when its source requires features outside these boundaries.
Check your environment and report clearly
Start with the bundled demo, then import your permitted list and select one channel. Record whether names appear, whether the Play control starts media, and whether playback time advances. Change one variable at a time so your comparison remains useful.
For a reproducible problem, include the exact browser and OS versions, demo result, input method and visible error in a contact report. Remove tokens and private source addresses. iiPTV browser compatibility information will be updated when additional tests are recorded; a content revision date alone does not certify a new browser. Return to the player to test your source against the published boundaries.