What is a magnet link?

A magnet link is a link that names a BitTorrent swarm by a fingerprint of its metadata instead of pointing at a file on a server. Your client reads that fingerprint, finds peers who have the same one, and picks up everything else from them. No .torrent file changes hands first, and no site has to stay up for the link to work.

Here is a real one, served exactly as it appears for Qwen_Qwen2.5-7B-Instruct in the catalog:

magnet:?xt=urn:btih:829a234188da34a2f758fc9b04abb4793faf95b0&dn=Qwen_Qwen2.5-7B-Instruct

The 40-character string is the infohash, and it is the only part your client needs; everything else in the link is convenience. The sections below cover what that string is and where its promise ends.

The six words, in one place

Half the trouble with torrent pages is vocabulary. Six words do most of the intimidating, so each gets a card: a plain definition, and why it matters to you.

• Magnet link

  A link that identifies a torrent by a hash of its metadata rather than by the location of a file. It starts with magnet: and its one required part is the infohash. You care because the whole swarm fits in a line of text you can copy, save, and hand to any client.

• Infohash

  The 20-byte SHA-1 fingerprint of a torrent's info dictionary, written as 40 hexadecimal characters. It is the name of the swarm. You care because every client, tracker, and signed manifest agrees on this one string, so it is the thing to compare when you want to know you are in the right swarm.

• Tracker

  A server that introduces peers to each other. Clients check in with it and get back a list of other clients that want the same torrent. It hosts no files. You care because the tracker list sits in the main area of the .torrent file, outside the hashed info section, so it can be replaced without changing the infohash.

• DHT

  The distributed hash table: a way for clients to find each other with no tracker at all. In effect each peer becomes a tracker, in the words of BEP 5 itself. You care because a magnet with no tracker addresses still works: the client is expected to fall back to the DHT. It is slower to start than a tracker.

• Peer

  Another client sharing the same torrent, reached at an address and a port. A peer holding a complete copy is called a seed. You care because with a magnet link, peers are also your only source for the metadata itself: until one of them hands over the info dictionary, nothing else can happen.

• Seeding

  Staying in the swarm after your download finishes, so that others can fetch from you. A completed torrent seeds on its own for as long as the client keeps running. You care because this is a preservation archive: a model stays obtainable only while the people who fetched it keep it available to others.

A real magnet link, taken apart

A definition will only carry you so far. Here is the same magnet again, with each part explained on its own terms:

magnet:?xt=urn:btih:829a234188da34a2f758fc9b04abb4793faf95b0&dn=Qwen_Qwen2.5-7B-Instruct

Two parameters, joined by an ampersand, and only the first one is required.

The xt part: the infohash

The letters stand for exact topic, and the value after urn:btih: is the infohash of the torrent, all 40 hexadecimal characters of it. This is the only mandatory parameter in the whole URI, as BEP 9 specifies, and the same specification asks clients to also accept a 32-character form left over from the early days of the scheme. Every torrent this archive publishes is the 40-character form. A later revision of BitTorrent defines a second URN for a different hash form, which you will not find in this catalog.

The dn part: the display name

A name for the client to show you while the real metadata is still on its way. It is optional, a client is free to ignore it, and once the info dictionary arrives the client can show the true name from inside the torrent instead. Treat it as a label for humans rather than as a statement about the contents.

The tr part: the trackers

An optional tracker address, in the same form the client would otherwise read out of the .torrent file. A magnet can carry any number of them, one tr each, and every one is a place for the client to look for peers. An address that begins with udp:// uses the UDP tracker protocol that BEP 15 defines.

Here is the same magnet with one tracker appended. The address comes from that torrent's own announce list, and it is shown as text only, because a tracker address is something your client consumes rather than something you visit:

magnet:?xt=urn:btih:829a234188da34a2f758fc9b04abb4793faf95b0&dn=Qwen_Qwen2.5-7B-Instruct&tr=udp://tracker.opentrackr.org:1337/announce

What the infohash actually hashes

The original protocol specification gives the definition in a single line, in BEP 3 quoted verbatim:

The 20 byte sha1 hash of the bencoded form of the info value from the metainfo file.

Unpacked into plainer words: a .torrent file is written in a compact format called bencode, and somewhere inside it sits a section named info that holds the torrent's name, the piece length, one SHA-1 hash per piece, and either a single file's length or the whole file list. The infohash is the SHA-1 of that section and nothing else.

One correction while we are inside the file, because the opposite claim circulates in guides: a .torrent file does not contain a DHT. Its required top-level keys are just announce and info alongside a few optional ones, and none of them is a DHT, because the DHT is a network your client joins rather than a field in any file.

The consequence is that the infohash is a fingerprint of the torrent's layout. Rename the payload directory, change the piece size, or add one file, and the infohash comes out different. That is why the same model, uploaded independently by two different people, arrives as two different torrents.

Why the infohash stays the same when trackers change

BEP 12 added multi-tracker support, and it places the announce and announce-list keys in the main area of the .torrent file, outside the info section. Since only the info section gets hashed, a tracker address cannot change an infohash, because it was never part of the input.

That is what makes a magnet link durable. Trackers die, get replaced, and get added, and none of it disturbs the hash. A magnet you saved in 2024 still names the same swarm after the tracker set around it has been rebuilt, and this archive can add trackers without breaking a single saved link.

Magnet, .torrent file, or bare infohash

Model pages give you two of these three, and the third is what the signed manifest hands you. The differences fit in one table.

Which client should receive any of the three, and which of the files inside the download you should point your tools at, belongs to the help page rather than to this one: it carries the client shortlist and the safetensors-versus-GGUF guidance.

How to open one

The steps are the same in every client; only the menu names move around.

1. Copy the whole magnet, from the m in magnet: at the start to the final character. Model pages show the link as selectable text beside the button, so there is no need to dig it out of a menu.
2. Add it in your client, with the add-torrent-from-link command that lives under a File menu or a plus button, or by pasting into the box the client offers. Clicking the link on the page works too, if you accept the browser handoff.
3. Wait out the metadata step. The client shows something like retrieving metadata while it collects the info dictionary from peers in 16 KiB blocks and checks what it receives against the infohash, so the metadata that arrives is known to be the right metadata.
4. Confirm the infohash. The client lists it in the torrent's detail view; compare it with the one printed beside the magnet on the model page. If they match, you are in the intended swarm.
5. Leave the torrent seeding when it finishes. A model in this archive stays fetchable only while completed copies stay in the swarm, and yours is about to be one of them.

When it goes wrong

Magnet trouble comes in three shapes, each with a cause and a fix that does not involve hunting down another copy of the files.

Nothing happens when you click

The click is ignored, or the browser asks what to open the link with and then quietly does nothing. The cause sits on your machine rather than in the link: nothing is registered to handle magnet: addresses. The fix is to skip the handoff entirely and paste the link into your client's add-from-link box. If you have no client installed yet, the help page has suggestions.

Stuck on retrieving metadata

The client sits in the swarm and downloads nothing. A magnet link does not carry the metadata, so your client is waiting for a reachable peer that has it, and there is not one right now. The honest fix is the .torrent file from the same model page: its metadata is complete, so there is nothing to wait for. The magnet can also recover on its own once a peer with the metadata comes online.

The tracker refuses the infohash

The message info hash is not authorized with this tracker looks alarming and is not. It comes from the tracker, not from your client. Private trackers accept only the torrents they issued to your account, so they reject any hash they do not recognize, including good ones. Your download is not corrupt, and the magnet is not broken.

What a magnet link cannot tell you

Everything above is about finding the right swarm. The infohash is also where the honesty has to start, because it is not a trust decision. A matching infohash means the metadata you joined is the metadata the link named: same files, same piece hashes, same swarm. It does not vouch for whoever published the link, and it has no opinion about whether the contents are what their label claims.

That second job belongs to the signed manifest: a single file listing every published model with its infohash, per-file digests, and provenance, under a minisign signature you check with one command. The walkthrough for that is the verify page with its three commands, and the verify-model-download guide holds the long version of the reasoning. If your question is whether torrenting model files is safe or lawful at all, the ai-model-torrents guide takes that one.