Wake-on-LAN Packet Builder

Build a Wake-on-LAN magic packet — and see why a browser cannot send it.

What you provide

Target MAC address

Broadcast address

The target's subnet broadcast, e.g. 192.168.1.255. A broadcast does not cross a router.

UDP port

9 is conventional; 7 also works.

Result

102-byte magic packet for 00:1a:2b:3c:4d:5e

A magic packet is six bytes of 0xFF followed by the target MAC repeated exactly sixteen times — 102 bytes in total. The repetition is what makes it recognisable to a network card that is otherwise asleep and doing no protocol processing at all, which is also why the UDP port barely matters: the card matches on the payload pattern rather than on the port. This page builds the packet and cannot send it, because browsers have no access to raw UDP. Send it with wakeonlan, a router's built-in function, or PowerShell — and note it must reach the target's broadcast domain, since a broadcast does not cross a router by default.

Diagnostic telemetry

Packet sizeSix bytes of 0xFF, then the MAC repeated sixteen times.: 102 bytes
Target MAC: 00:1a:2b:3c:4d:5e
DestinationUDP. Port 9 is the usual choice; 7 also works. The port is not really used — the packet is matched by content.: 255.255.255.255:9
Payload (hex): ffffffffffff001a2b3c4d5e001a2b3c4d5e001a2b3c4d5e…
Sent from this pageBrowsers cannot send raw UDP. The packet is built here for you to send with a tool that can.: No

What this cannot tell you

Builds the packet and cannot send it. Browsers have no access to raw UDP, so no web page can wake a machine — one claiming to is either using a helper you installed or not doing what it says.
A magic packet is a broadcast and does not cross a router by default. It must originate inside the target's own broadcast domain unless the router is configured to forward it.
Wake-on-LAN must also be enabled in the target's firmware and network adapter settings. The packet arriving is not sufficient on its own.
Runs entirely in your browser. Nothing is looked up, transmitted or stored.

Take this with you

How this calculation works

A magic packet is six bytes of 0xFF followed by the target MAC address repeated exactly sixteen times — 102 bytes in total. The repetition is what makes it recognisable to a network card that is otherwise powered down and doing no protocol processing whatsoever, and it is also why the UDP port hardly matters: the card matches on the payload pattern rather than on the port, so 9 and 7 are conventions rather than requirements. This page assembles the packet for you to send with something that can. A browser cannot: there is no raw UDP access from a web page, by design.

What the results mean

102 bytes: Six 0xFF bytes plus the MAC sixteen times. The repetition count is the part implementations get wrong.
Broadcast address: Must be the target's own subnet broadcast. A broadcast does not cross a router.
UDP port: Conventionally 9 or 7, and largely irrelevant — the card matches the payload, not the port.
Sent from this page: No. Browsers have no raw UDP access, and a page claiming otherwise is not doing what it says.

Common problems and fixes

The machine does not wake: Check the firmware setting first — Wake-on-LAN is off by default on most machines — then the network adapter's power management, which often disables it to save power on battery.
It works on the same network but not remotely: Broadcasts do not cross routers. You need a directed broadcast the router will forward, a port forward to the target, or a device already inside the network to send it.
Can this page just wake my machine?: No. A web page cannot send raw UDP. Use wakeonlan on Unix, a router's built-in function, or PowerShell.

Frequently asked questions

Why is the MAC repeated sixteen times?

So the pattern is unmistakable to a network card doing almost nothing. A sleeping card is not running a protocol stack — it scans incoming frames for that specific repetition, which is unlikely to occur by accident.

Does the UDP port matter?

Barely. The card matches on the payload rather than the port, so 7 and 9 are conventions. Anything that reaches the card works.

Why can a website not send this?

Browsers give pages no access to raw UDP sockets, deliberately — it would allow arbitrary packets to be sent to any host on your network from any page you visited.

Put this on your own site

Free to embed, no attribution required beyond the source link the frame carries itself. It runs entirely in your visitor's browser, sets no cookies and loads no third-party script.

Embed code

<iframe src="https://runthetests.com/embed/wake-on-lan/" width="100%" height="560" style="border:1px solid #e5e5e5;border-radius:8px" title="Wake-on-LAN Packet Builder" loading="lazy"></iframe>

Preview it at https://runthetests.com/embed/wake-on-lan/. Embedded pages are marked noindex, so yours stays the canonical copy — not this one.