Xtream server URL: what it is, where to find it, and what each field expects

An Xtream login is three values: a server URL, a username and a password. Two of them are obvious — you can see the username and the password in the message that carried them. The server URL is the one people end up guessing at, because it looks like a web address, sits next to other web addresses, and behaves differently from all of them.

The Xtream ↔ M3U URL converter builds every URL that comes out of those three values, entirely in your browser. This page is about the first of the three on its own: what belongs in the server field, where the value comes from, and what to check when a player rejects it.

What the server URL contains

A server URL describes the machine, not the account. It has three parts and nothing else:

http://server.example:8080

• Scheme — http:// or https://. Most Xtream servers respond on plain http://.
• Host — the name or address of the server, server.example in the form above.
• Port — :8080 in the form above. Usually not 80 or 443; high ports are the norm here.

There is no path, no trailing slash and no query string. http://server.example:8080 is a complete server URL; http://server.example:8080/get.php is not — that is a playlist endpoint, and pasting it into a server field is one of the two mix-ups this page exists to prevent.

It is not the same value as the M3U URL

The three Xtream values and a single M3U URL describe the same access, in two different shapes. A player asks for one or the other:

• A player with Server / Username / Password fields is asking for the Xtream login. The server field takes the bare server URL above.
• A player with one M3U URL or Playlist URL field has no server field at all. It wants the whole address, credentials included, which is a longer string with a /get.php path and query parameters.

If a player asks for the second shape and you only have the first, convert rather than guess: the converter takes the server, username and password and returns the matching M3U URL, the XMLTV URL and the player_api endpoint. The step-by-step guide covers the formula itself and the edge cases around it.

Where the value comes from

The server URL arrives the same way the username and password do — in the message, activation email or customer panel of whoever supplied the subscription. It is part of your credentials, so it is worth the same care as the password:

• Treat the whole three-part login as one credential. Any page that asks you to type it in is asking for your access.
• Do not accept a server URL from a search result, a forum post or a video description. A server URL you did not receive with your own login is not your login.
• If you cannot find it, the source to ask is the one that issued the login. Nobody else can tell you which machine your account lives on.

What each player calls that field

The field name varies far more than the value does. These all mean the server URL:

• Server URL, Server address, Server
• Host or Hostname, sometimes split into host and port as two fields
• Portal URL
• Xtream server or API URL, in players that label the whole login after the protocol

If a player splits host and port, the host part is the value without the http:// and without the port, and the port goes in its own field. If a player offers a placeholder such as http://server.example:8080, that placeholder is showing the expected shape — scheme, host, port, nothing after it.

A separate EPG URL or XMLTV URL field, where a player has one, is a different value again: it takes the guide address rather than the server.

Why a correct server URL can still fail

A server URL can be perfectly well-formed and still not work, and the failure usually looks the same in every case. Check these before assuming the login is wrong:

• A path pasted in. /get.php, /player_api.php or /xmltv.php left on the end of the server value. Strip everything after the port.
• A missing port. If the value has no port and the player rejects it, the port was probably dropped when the credentials were copied.
• Whitespace from a copy-paste. A trailing space or newline turns a valid host into an invalid one. Most players reject it outright rather than trimming it, and some silently treat it as a different server.
• https:// on a server that only serves http://. A certificate error or a 404 on a server URL often means the scheme is wrong, not the host.
• A stopped or expired account. The URL describes a machine. It cannot tell you whether the subscription on that machine is still active.

There is a limit worth stating plainly: those checks confirm the shape of the value, not your access. To test the access itself, paste the three values into the Xtream credentials checker — it distinguishes an authentication failure from an unreachable server from an expired subscription. To test the resulting address instead, paste it into the M3U playlist tester.

If the checker reports an authentication failure on credentials you are sure about, that is a different problem with its own diagnostic: why Xtream says authentication failed.

When there is no server URL at all

Not every source is an Xtream login. A source can also be a plain M3U or M3U8 playlist URL with no username, password or server field anywhere in it — the address is the whole credential. Those URLs have no Xtream-equivalent set of three values, because nothing generated them from an account on a server.

If that is what you were given, there is nothing to put in a server field. Use the URL as-is in a player that accepts a playlist URL, and see Xtream Codes vs M3U for which shape to lead with when a player supports both.

What this looks like in Klipa

Klipa accepts both shapes side by side in the same library. An Xtream source is added as the three fields — server, username, password — and an M3U source is added as one URL. Adding both from the same login is supported, and each is refreshed independently, so a failure in one does not take the other with it.

That is the whole of the server field: one host, one port, no path, handled like the password beside it.