What Is a Magnet Link? Magnet URIs and Info Hashes Explained

A .torrent file is the full description of a torrent: file names, sizes, and a hash for every piece. A magnet link is just the fingerprint of that description. Hand the fingerprint to a torrent app and it asks the network, "who has the torrent that hashes to this?", fetches the description from whoever answers, and checks it is the right one.

That one idea explains almost everything about magnet links: why they are tiny, why they cannot be tampered with in transit, and why they sometimes sit on "downloading metadata" for minutes. This guide takes a real link apart, explains what the hash actually covers, and walks through what your client does between the click and the first byte of video. If you just want to open one, how to open and play a magnet link has the steps for each system.

Anatomy of a magnet link

Here is the magnet link for Sintel, Blender's open movie (CC BY), as published on WebTorrent's free torrents page. It lists eight trackers; this copy keeps one so it fits:

magnet:?xt=urn:btih:08ada5a7a6183aae1e09d831df6748d566095a10
  &dn=Sintel
  &tr=udp%3A%2F%2Ftracker.opentrackr.org%3A1337
  &ws=https%3A%2F%2Fwebtorrent.io%2Ftorrents%2F
  &xs=https%3A%2F%2Fwebtorrent.io%2Ftorrents%2Fsintel.torrent

(A real link is one unbroken line; the line breaks are only for reading.)

It is a URI like a web address, but instead of https://host/path it starts with magnet:? and is nothing but parameters. Values are percent-encoded, so udp%3A%2F%2Ftracker.opentrackr.org%3A1337 decodes to udp://tracker.opentrackr.org:1337.

Where the format comes from

The magnet scheme predates its use in BitTorrent. It was drafted in June 2002 by Gordon Mohr of Bitzi as a vendor-neutral way to name files by their hash, so any program could offer options for "this exact file". That original draft defines xt (exact topic), dn (display name), kt (keyword topic), mt (manifest topic) and reserves names starting with x. for experiments.

BitTorrent adopted the scheme in BEP 9, which defines the BitTorrent-specific parts. Other parameters appear in the wild, and support for them varies by client.

The parameters

Parameter	Meaning	Where defined	Notes
`xt`	Exact topic: the info hash	Magnet draft, BEP 9	The only required part
`dn`	Display name	Magnet draft, BEP 9	Shown while metadata loads; not verified
`tr`	Tracker URL	BEP 9	Optional; can repeat
`x.pe`	A peer address to try	BEP 9	Optional; can repeat; rare
`ws`	Web seed: an HTTP server with the same files	Common extension	Read by libtorrent
`so`	Select only these files	BEP 53	Zero-based, e.g. `so=0,2,4-6`
`xs`	Exact source, such as a `.torrent` URL	General magnet usage	Ignored by libtorrent
`xl`	Exact length in bytes	General magnet usage	Ignored by libtorrent
`as`, `kt`	Fallback download, keyword search	General magnet usage	Rarely used for torrents

libtorrent is the library inside qBittorrent and Deluge, among others, so what it reads is a good guide to what matters in practice. Its magnet parser understands xt, dn, tr, ws, so and x.pe, plus a non-standard dht parameter for a bootstrap node, and skips the rest.

xt: btih and btmh

The xt value is a URN that says which kind of hash follows:

urn:btih: carries a version 1 info hash. BEP 9 specifies it as 40 hexadecimal characters, and says clients should also accept the 32-character base32 form found in older links.
urn:btmh: carries a version 2 info hash in multihash format: the prefix 1220 (12 means SHA-256, 20 means 32 bytes) followed by 64 hex characters.

A link can carry both. BEP 9 says "'btmh' and 'btih' exact topics may exist in the same magnet if they describe the same hybrid torrent", a torrent built so that v1 and v2 clients can share it. libtorrent's v2 test link looks like this:

magnet:?xt=urn:btmh:1220caf1e1c30e81cb361b9ee167c4aa64228a7fa4fa9f6105232b28ad099f3a302e&dn=bittorrent-v2-test

What an info hash is

Every torrent has an "info" dictionary: the part of the .torrent file that holds the suggested name, the piece size, and either one file's length or a list of files with their paths and lengths. It also holds the hashes that verify the data, a 20-byte SHA-1 hash for every piece in version 1.

The info hash is a hash of that dictionary, exactly as encoded in the file. Change one byte, such as a file name, the piece size or a single piece hash, and the info hash changes completely.

That gives a magnet link a chain of trust from a single short string:

The info hash pins the info dictionary.
The info dictionary pins the hash of every piece.
Every piece you download is checked against its hash.

So a 40-character link is enough to guarantee that every byte you end up with is the byte the torrent's creator hashed. It does not guarantee the creator was honest about what those bytes are; more on that below.

v1 and v2 info hashes

	Version 1 (BEP 3)	Version 2 (BEP 52)
Hash function	SHA-1	SHA-256
Info hash length	20 bytes (40 hex)	32 bytes (64 hex)
Magnet prefix	`urn:btih:`	`urn:btmh:1220`
Piece verification	One hash per piece	A hash tree per file, built from 16 KiB blocks

Version 2 was introduced into the specification in 2017 and became widely usable with libtorrent 2.0 in 2020; qBittorrent supported it from 4.4.0, released in January 2022. The switch to SHA-256 came in the same year that researchers at CWI Amsterdam and Google published the first practical SHA-1 collision, in February 2017. It also gives every file its own hash tree, so identical files have identical hashes whichever torrent they are in.

There is a practical wrinkle. Trackers, the DHT and the peer handshake all use 20-byte identifiers, so v2 truncates its SHA-256 info hash to 20 bytes for those. The truncated v2 hash is different from the v1 hash of the same content, so a v1 torrent and a v2 torrent of the same files form two separate swarms. Hybrid torrents exist to bridge them, which is why a hybrid magnet link carries both hashes.

How a client turns a magnet link into a download

A magnet link contains no file list and no piece hashes. Your client has to get the info dictionary, known as the metadata, from other peers first. It happens in four steps.

1. Find peers

The client uses every peer source it has, in parallel:

Trackers listed in tr=. A tracker is a server that keeps a list of peers for each info hash. Ask it, and it answers with addresses.
The DHT (BEP 5), a distributed hash table that clients share among themselves over UDP. It is based on Kademlia: each node has a random 160-bit ID from the same space as info hashes, and a get_peers query walks towards the nodes whose IDs are closest to the hash you want. In the BEP's words, "each peer becomes a tracker." BEP 9 says that if a link has no tracker, the client should use the DHT.
Peer exchange (BEP 11). Once connected to one peer, your client can learn about others from it. Updates are batched to at most one message a minute, with up to 50 added peers in each after the first.
x.pe addresses, if the link includes any.

2. Download the metadata

Peers talk through the BitTorrent extension protocol (BEP 10). A peer that can share metadata advertises ut_metadata in its handshake, along with metadata_size, the size of the info dictionary in bytes.

Your client then requests the metadata in numbered 16 KiB blocks. A peer answers each request with the block (a "data" message) or turns it down (a "reject" message). A peer that does not yet have the complete metadata itself must reject every request, so only peers that already have it can help.

3. Verify it

When every block has arrived, the client hashes the assembled metadata and compares the result with the info hash from the link. If they differ, the data is thrown away. A peer cannot slip you a different file list, because it would need to produce a different dictionary with the same hash.

4. Download normally

From here a magnet link behaves exactly like a .torrent file. The client knows the files, sizes and piece hashes, picks which pieces to fetch, and checks each one as it arrives. Web seeds from ws= can now contribute data too. If you want the bigger picture of pieces, swarms and choking, see how BitTorrent works.

Magnet link vs .torrent file

They lead to the same torrent and the same swarm. The difference is whether the metadata arrives with the link or has to be fetched.

	Magnet link	`.torrent` file
What it contains	Info hash, optional name and trackers	Full metadata: files, sizes, piece hashes, trackers
Size	One line of text	A small file
Sharing	Copy and paste anywhere: chat, email, a web page	A file to download or attach
Start-up	Waits for metadata from peers	Starts immediately
Dead torrent	Shows nothing, not even the file list	Shows the file list, even with no peers
Private trackers	Needs the tracker in the link	Works as designed
Tamper resistance	Metadata verified against the hash	Same, once you have the right file

When magnets are better

Magnet links are easy to share, cost a site nothing to host, and cannot go stale the way a hosted file can if a server disappears: as long as someone in the swarm has the torrent, the hash will find it. They are also easy to inspect. You can read a magnet link and see exactly which hash and trackers it uses.

When a .torrent file is better

A .torrent file skips the metadata wait entirely, which matters for rare torrents where few peers are online. It shows the file list straight away, so you can choose files before connecting to anyone. And on private trackers, which only allow their own tracker to hand out peers, the .torrent file is the normal way in.

Some links include xs= pointing at a copy of the .torrent file, as the Sintel link above does, so clients that understand it can fetch the metadata over HTTP instead. WebTorrent does this, and checks the downloaded file against the info hash before using it.

Why magnet links get stuck on metadata

"Downloading metadata" (or "retrieving metadata") means step 2 has not finished: your client has not yet found a peer that has the complete metadata and will send it. The usual causes, from most to least common:

Nobody who has it is online. An old or obscure torrent may simply have no peers. No setting can fix that.
No way to find peers. A link with no tr= depends entirely on the DHT. If the DHT is turned off, or UDP traffic is blocked by a firewall, router or VPN, the client has nothing to ask. Some apps disable the DHT on purpose in privacy modes; TorrentPlayer does when it runs through a VPN adapter, its built-in WireGuard tunnel or a SOCKS5 proxy, so magnet links there need working trackers.
Private torrents. BEP 27 says a client "MUST ONLY announce itself to the private tracker", and its rationale rules out the DHT and peer exchange for such torrents. A magnet link for a private torrent without its tracker URL cannot find anyone.
Peers that cannot share metadata. Metadata exchange is an extension. A peer whose client does not support it, or that does not have the full metadata yet, cannot help.
A v2-only link in a v1-only client. A client without v2 support has no use for a link that carries only a btmh hash.
Slow DHT bootstrapping. A client that has just started, or that has an empty routing table, may need a minute or two before DHT lookups return anything.

The fixes, step by step, are in retrieving metadata stuck. If metadata arrives but the download then crawls, that is a different problem, covered in why a torrent is slow or stuck.

Are magnet links safe?

The link is plain text. It cannot run anything, install anything, or contain a virus. Opening one only tells your client which hash to look for.

What it points to is a different matter. The hash guarantees you receive exactly the content the torrent's creator hashed, not that the content is what the name says. The display name is explicitly untrusted: the original magnet draft calls it the "(unverified) 'display name'", and anyone can put any name on any hash.

A few habits keep you out of trouble:

Check the file list once metadata arrives. Your client can show it as soon as the metadata is in, and many let you review it before any content downloads. A film should contain video files and perhaps subtitles. An .exe, .scr, .bat or .lnk file, or an archive with a password, in a torrent that claims to be a video is a red flag. Delete it.
Get magnet links from sources you trust. The official site of a Linux distribution, the Internet Archive, Academic Torrents or a project's own page are safer than a random link in a comment.
Remember that peers see your IP address. While a magnet link is downloading, everyone in the swarm can see your address, as with any torrent. VPN for torrenting explains the options.
Mind what you download. BitTorrent and magnet links are legal technology. Downloading copyrighted material without permission usually is not, and that is about the content, not the link format. Is torrenting legal? covers the general principles; it is not legal advice.

Opening and playing a magnet link

Any BitTorrent client accepts magnet links: paste the link in, or set the app as your system's handler so clicking a link opens it. To watch something without waiting for the whole download, a streaming player such as TorrentPlayer starts playback within seconds of the metadata arriving and fetches whatever point you skip to. It is free and open source, though still an early preview, and its player cannot yet decode AC-3 or DTS audio. The Sintel link above is a good one to test with.

Step-by-step instructions for Windows, Mac and Linux, plus browser settings, are in how to open and play a magnet link.

Sources

Checked on 20 October 2026.