Why some links can't be checked in the browser

M3U.Click runs entirely in your browser, with no server of its own in between. That keeps your playlists private, but it also means the editor must follow the browser’s security rules. Three of them decide whether a link can be checked, previewed or imported.

1. CORS: websites can’t read other websites

A web page can ask for data from another website only if that website allows it. The permission is a response header called Access-Control-Allow-Origin, part of a system called CORS (Cross-Origin Resource Sharing). Without it, the browser fetches the response but won’t let the page read it.

Most stream and playlist servers don’t send this header, because they were built for players, not for web pages. So, in the browser:

Import from a link can work only if the server allows it. When it doesn’t, M3U.Click tells you and suggests downloading the file and opening it.
Link checks can still learn something. The browser can tell whether a server answered at all, but not what it answered. M3U.Click labels these entries reachable, never “working”, because the answer could be an error page.

Import from a link and link checks arrive with the next editor updates; this guide explains how they will behave.

A page can’t switch CORS off. The usual workaround is a “proxy” server that fetches the link for you. M3U.Click deliberately doesn’t use one: it would mean your playlists and links passing through our servers.

2. Mixed content: secure pages can’t load insecure links

M3U.Click is served over HTTPS. Browsers protect secure pages by blocking or changing requests to plain http:// addresses (“mixed content”):

Data requests to http:// addresses, such as importing a playlist or checking a link, are blocked.
Audio, video and images from http:// addresses are automatically upgraded to https://. If the server doesn’t support HTTPS, they fail. Chrome does this for audio and video since version 80 and for images since version 86, Firefox since version 127, and Safari since version 18.
Addresses that use an IP number (such as http://203.0.113.5:8000/) are not upgraded: they are simply blocked.

Many radio streams and older servers still use http://. In the browser, M3U.Click reports these entries as blocked by the browser rather than “dead”, because the stream may be perfectly fine.

3. Your home network needs permission

Addresses on your home network, such as a media server at http://192.168.1.10:8096, are treated specially:

Chrome 142 and later ask for permission before a website can reach devices on your local network. If you allow it, requests to those private addresses are also exempt from the mixed-content block, so importing from your own server can work, as long as the server allows it through CORS.
Other browsers handle this differently and may block such requests.

M3U.Click explains the prompt before a check that includes home-network addresses.

What the link-check labels mean

Link checks only run when you start them. The results use these labels:

Label	Meaning
Dead	No answer, or a clear error such as “not found”
Slow	The server answered, but only after a long wait
Redirected	The server sent the request on to a different address
Reachable	The server answered, but the browser wouldn’t let us read the answer (CORS), so we can’t say more
Blocked by the browser	The browser’s rules stopped the check (usually an `http://` address). The entry is not necessarily broken

What you can do

Open the playlist file instead of the link. Download it with your browser, then open the file in M3U.Click.
Test in a player. Desktop players such as VLC aren’t bound by these browser rules.
Ask for HTTPS. If you run the server, enabling HTTPS and CORS makes it work in browsers.
Use the apps when they arrive. M3U.Click apps for Android and iOS are planned. Apps aren’t limited by CORS and can check http:// links.