XDCC explained: how IRC file-serving bots work

XDCC — eXtended DCC — is a bot that sits in a channel holding a numbered catalogue of files and sends you one when you ask for it by number.

It is thirty years old, it predates every file-sharing service you have used, and on a few networks it is still busy.

How it works #

Two separate things happen, and keeping them apart explains most of XDCC's behaviour.

The request goes through the server. You send the bot a private message naming a pack number. That is ordinary IRC text.

The file does not. The bot opens a DCC connection straight to your machine and the data flows peer to peer. The IRC network carries none of it, which is exactly why the model survived — the bot's operator supplies the bandwidth, and the network is not hosting anything.

A pack is just an index. The bot's list looks roughly like this:

#1  12x [1.4G] Some.File.Name.mkv
#2   4x [702M] Another.File.Name.mkv

The number on the left is what you ask for; the 12x is how many times it has been sent.

The commands #

Addressed to the bot by private message:

/msg BotName xdcc list        # the catalogue, where the bot offers one
/msg BotName xdcc info #5     # size and description of one pack
/msg BotName xdcc send #5     # request it
/msg BotName xdcc cancel      # abort a transfer in progress
/msg BotName xdcc remove      # leave the queue

Bots are usually running iroffer or one of its descendants, so the syntax is near-universal. Some channels use a trigger in the channel itself instead (!botname 5), and busy bots put you in a queue with a slot limit — the list command tells you how many slots and how long the queue is.

Transfers resume. A bot that supports it will pick up an interrupted file where it stopped, which mattered a great deal in 2003 and is still convenient.

Why the search engines exist #

No bot advertises itself outside its own channel, so finding a specific file means knowing which bot on which network has it. Third-party sites crawl channels, collect the packlists, and let you search across them — that is all an "XDCC search engine" is, and it is why xdcc search gets looked up far more than xdcc itself.

Most of what they index is anime and fansub material, historically centred on Rizon, and most of it is copyrighted.

The safety rules #

XDCC hands an unknown party a direct connection to your machine, so the DCC safety rules apply at full strength:

• Your IP is exposed, and so is the bot's. A direct transfer cannot work otherwise. Running through a bouncer on a VPS makes that the VPS's address instead — see security and privacy.
• Turn DCC auto-accept off. Verify it rather than assuming; modern clients default safely, inherited configs often do not.
• Check the real extension. episode.mkv.exe is the 1999 trick and it still lands on someone every year.
• A bot is not a guarantee of anything. Nobody vets what a bot serves, and a pack description is written by whoever runs it.

The legal part, plainly #

XDCC is a transfer mechanism and there is nothing unlawful about it — projects have used it to distribute their own releases, and some still do.

What sits on the public search engines is a different question, and largely answers itself. Downloading unlicensed copies is illegal in most places regardless of which protocol carries it, and IRC offers no anonymity whatsoever — your address is visible to the bot by design.

That is the description; the decision is yours.

Is it worth using in 2026? #

For distributing your own large files to a technical audience that is already on IRC, it works, costs nothing, and needs no account anywhere.

For anything else, the honest answer is that the rest of the internet solved this problem with HTTPS and a link. XDCC persists where the community and the habit persist — which, on a couple of networks, is still a real place.

More on the underlying mechanism in DCC explained.