Who uses Wake-on-LAN, and what for
A computer is useful while it is running and wasteful, hot and noisy when it is left that way for nothing. The arrangement that fixes that is the same for everybody: the machine sleeps by default, stays awake while it is genuinely being used, goes back to sleep afterwards — and comes back when you ask for it. Wake-on-LAN, a mechanism from the late 1990s, is that last step, and it is the step whose answer depends on the hardware you own. Six quite different kinds of people arrive at it from six different directions, and they need different things once they get there.
This page is the map. It covers who reaches for Wake-on-LAN and why, what each of them actually needs beyond the packet itself, and — because it matters more than the sales pitch — where a simpler answer than any of this is the right one. If you want the steps before the map, how to wake a PC remotely is the plain walkthrough for any machine, and how to wake a Mac remotely the Mac's own, Wi-Fi caveat included.
The one thing all five have in common
A desktop idling does something between 40 and 100 watts, and a machine with a serious graphics card can sit well above that doing nothing at all. Asleep, the same machine draws roughly two to five watts, and it comes back in a couple of seconds with every window where you left it. The gap between those two numbers is the entire reason Wake-on-LAN exists.
What the protocol gives you is one thing only: a specially formed broadcast — the magic packet — that a network card listens for while the rest of the machine is off. There is no acknowledgement, no status, no reply. It is a doorbell with no intercom, and everything anyone builds on top of it is an answer to that.
Gamers, and the rig that should not idle
A gaming PC is the worst machine in the house to leave running and the best one to reach remotely. Somebody who streams from their own rig to a handheld, a laptop or a TV wants the machine asleep between sessions and awake about fifteen seconds before they start playing — then asleep again afterwards, without walking to the desk.
What they need beyond the packet: the wake and the connection in one motion, so the streaming client opens the moment the machine is actually up rather than a hopeful few seconds later. Waking a gaming PC remotely covers the setup, the BIOS settings that stop it working, and the handoff. Waking your PC for Steam Link, Moonlight or Parsec is the streaming client's version of the same page: wake, confirm, connect, then sleep it again.
Remote workers, and the desktop somewhere else
The machine with the licences, the local files and the environment on it is at the office or at home, and the person who needs it is not. The path most people fall into is leaving it running and opening a Remote Desktop port at the router — which is how a large share of ransomware gets its first foothold, and how most people who have done it find out.
What they need beyond the packet: a way to reach the machine that does not involve an open door, and a way to know it woke before they are sitting in a hotel with a laptop. Waking your work PC from home covers the safe shape, the checks to run before you travel, and the sign-in trap that catches people who use a PIN or a fingerprint on the machine they are trying to reach. A student away in term time has the same problem with the desktop at home, and a network in halls they cannot change: waking your home PC from university covers that shape, the family sender included. And if the tool is the problem — the PC has gone to sleep by the time the client connects — remote desktop, but the PC is asleep is the page for that.
Households and businesses where more than one person needs the machines
The moment a second person needs to wake something, the usual answer is to pass a password around — and passwords that get passed around do not get revoked when somebody leaves. A family sharing a media server and a five-person office sharing a till PC and a design workstation have the same problem in different clothes.
What they need beyond the packet: separate sign-ins with different rights, a record of who did what, and revocation that takes one click. Wake-on-LAN for a team covers the role ladder, sharing single machines rather than whole accounts, and handing somebody a wake button when they have no account at all.
IT teams with a patch window and a fleet
Updates land on machines that are switched off overnight, which means either patching during the working day or somebody walking the floor pressing power buttons. Waking a fleet at 02:00, letting the updates run, restarting them and putting them back to sleep is the oldest legitimate use of this protocol there is.
What they need beyond the packet: schedules that retry and report, a restart after the updates land, the same action across a whole site at once, and a record they can hand to somebody who asks. Wake-on-LAN for patch windows covers all four.
Homelabs and NAS owners, who already own the hard part
Anyone with a Raspberry Pi, a NAS or a small server humming in a cupboard already has the thing everybody else has to buy: a machine that never sleeps and can put a broadcast on the local network. What they usually want is the opposite of a purchase — to use what is already there, and to spin the big power-hungry box up only when a job needs it.
What they need beyond the packet: software on the always-on box, and the arithmetic about when a dedicated device beats it. Wake-on-LAN for a homelab covers both, along with self-hosting the whole service. The server that should sleep between jobs — up for an SSH session or the nightly copy, asleep again after, with no inhibitor script — is sleep your Linux box and still SSH in.
Developers, and the machine a coding agent needs awake
The newest arrival, and the oldest problem wearing new clothes. Claude Code's remote control lets a developer drive a live coding session from a phone or any browser — but the session runs on a real machine, and that machine has to be awake, with the session started at its own keyboard. So the dev box stays on all night for a session that runs two hours, or somebody keeps a remote-desktop route open just to type one command into a terminal the size of a postage stamp.
What they need beyond the packet: the wake, a hold that keeps the machine up exactly as long as the session and no longer, the session started with nobody at the keyboard, and the handoff into the Claude app. Running Claude Code remotely on a PC that sleeps covers the one-button version of all four, the setup, and the traps nobody else documents.
Where a simpler answer is the right one
Not every version of this problem needs a service, and a page that pretended otherwise would not be worth citing. If the machine is a headless box you leave on anyway, waking it is a solved problem — do nothing. If you need a machine cold-booted rather than resumed, and its motherboard is set to power on after a power loss, a smart plug does that for the price of a takeaway. If you own a voice assistant and one machine, a free skill can broadcast the packet for you.
And there are cases where Wake-on-LAN itself is the wrong tool. A target on Wi-Fi rather than Ethernet is best-effort at best: waking over Wi-Fi means WoWLAN, support varies by adapter and driver, and key rotation on the network interferes with it. A machine behind client isolation, on a guest SSID, or on a different VLAN from your emitter cannot be reached at all — a broadcast physically does not cross those boundaries, and no product can change that.
Where it does fit, the question is not whether something can send the packet. Everything can. It is what happens afterwards: whether anything checks the machine came up, whether anyone can tell you why it did not, and whether the arrangement survives the person who set it up leaving.