xdotool, ydotool, dotool or Playwright: Which Automation Tool Fits a Headless Server?

If you have ever needed a script to click, type and post for you on a Linux machine, you have met four names: xdotool, ydotool, dotool and Playwright. They look similar from far away, but they work in very different ways. Today, October 20, 2026, this question matters more than it used to, because many Linux desktops now run Wayland instead of the older X11 system, and that changes which tool works at all.

This article shares what we learned while automating a small company's daily social-media posting job. The job runs on a server with a private, invisible screen, and it posts one article a day to several sites. We chose between these tools, switched one step from one tool to another, and measured the cost.

The short answer

For a job on an invisible X11 screen, use Playwright when the site is a normal web page, and keep xdotool as a backup. ydotool and dotool are built for a different problem. On CPU and memory, the difference between Playwright and xdotool is small. Reliability matters far more.

What each tool actually does

xdotool talks to an X11 display. It can move the mouse, click, type, press keys, and find windows by name. It sends input only to the display you point it at. It cannot see the screen, so if you need to know what is on screen you must take a screenshot yourself.

ydotool and dotool work lower down. They write to the kernel's input device (called uinput), so they behave like a real keyboard and mouse plugged into the whole machine. That is why they work on Wayland, where xdotool does not. The price is that they cannot choose a window and they send input to whatever has focus on the real desktop. They also usually need extra permission to use the input device.

Playwright is different in kind. It does not fake a mouse or keyboard. It connects to the browser and controls the web page itself. It can wait for a button to appear, read the text in a box, and tell you if a message showed up.

Why the screen type decides most of it

Our job runs on a private virtual display, which is a screen that exists only in memory, so nobody can watch it. This is X11, so xdotool works. ydotool and dotool would send their input to the whole machine, which could land on the real console desktop. In our case that desktop must stay locked, because another administrator can see its screen. So those two were ruled out for safety, not for speed.

We did not run ydotool or dotool in this test, so we have no CPU or memory numbers for them. What we can say is based on how they work.

Step 1: Find out where the old method fails

Our first version used xdotool plus screen reading (OCR). It opened the posting page, pressed a key to send, then took a screenshot and read the text to look for "Your post was sent".

The problem was the confirmation. Several times the post was live, but the script missed the message and reported "FAILED". A person then had to check the profile by hand. This is the main weakness of any tool that only sends input: it cannot know what happened, so you guess from a picture.

Step 2: Move the step to Playwright

We attached Playwright to the browser that was already running on the private screen, through its local debugging port. The script now waits for the compose box, checks that our text is in it, checks the Post button is enabled, clicks it, and waits for the confirmation. If the message is missed, it looks at the profile for a fresh post before it calls anything a failure.

We kept the old xdotool route as a fallback. If the Playwright step fails for any reason, a warning is sent and the old route tries instead.

Step 3: Measure the cost

We ran one dry run of each route, with the post discarded at the end, and measured it with the standard time command.

/usr/bin/time -f "wall %es  cpu %U+%Ss  peak RAM %M KB" <command>

	Playwright	xdotool plus OCR
Wall time	9.3 seconds	20.2 seconds
CPU time (user plus system)	1.4 seconds	1.1 seconds
Peak memory	about 165 MB	about 51 MB

These are single measurements, not averages, so treat them as a rough guide.

Playwright uses about 110 MB more memory, because it starts a Node process. CPU is almost the same. Playwright finishes sooner, because it waits only until the page is ready, while the xdotool route uses fixed waits.

The biggest cost was neither tool. The browser itself used about 4.6 GB across its processes, and both routes share it. Choosing between these tools does not change that number.

Step 4: Decide with a simple rule

1. If the target is a web page and a browser is available, use Playwright. It reads the page, so it knows what happened.
2. If you must control something that is not a web page, on an X11 display, use xdotool and read the screen to check results.
3. If you must control a real Wayland desktop, use ydotool or dotool, and accept that input goes to the whole machine.
4. Where a site offers a free official API, use that before any of them.

Conclusion

On resources, xdotool is lighter by about 110 MB of memory, and the CPU difference is too small to matter. On reliability, Playwright wins clearly, because it checks the page instead of guessing from a picture. For a job that runs once a day, a second of CPU and a little memory are not the real cost. A false "failed" report that sends a person to check by hand is.

Merits

• Playwright reads the page, so it can confirm that an action worked.
• Playwright is not tied to screen positions, so small layout changes break it less often.
• xdotool is very light and needs no extra software beyond X11.
• xdotool sends input only to the display you choose, which keeps a locked desktop safe.
• ydotool and dotool work on Wayland, where xdotool cannot.
• Keeping a second route as a fallback means one failure does not stop the job.

Demerits

• Playwright uses more memory than a simple xdotool call.
• Playwright depends on the page's element names, which a site can change without notice.
• xdotool cannot see the screen, so it needs OCR or screenshots and can report false failures.
• ydotool and dotool send input to the whole machine and cannot pick a window.
• ydotool and dotool usually need access to the kernel input device.
• Browser automation of a site may be against that site's terms, so keep the volume low.

Caution

This article is educational and describes one setup. The numbers come from a single dry run on one machine and will differ on yours. Replace any placeholder values with your own, check how each tool behaves on your display system before relying on it, and read the terms of any site you automate. We did not measure ydotool or dotool, so verify their cost yourself.

Frequently asked questions

• Which is best for automation on a Linux server? — For web pages, Playwright. For non-web programs on an X11 display, xdotool. The choice depends on what you are controlling.
• Does xdotool work on Wayland? — Not for the real Wayland desktop. It needs an X11 display, such as a virtual one.
• What is the difference between ydotool and dotool? — Both write to the kernel input device and work on Wayland. They differ mainly in how you give them commands and how they are set up.
• Which uses less CPU and RAM? — In our test, xdotool used about 110 MB less memory, and the CPU time was almost the same.
• Is Playwright slower? — No. In our test it finished in 9.3 seconds against 20.2 seconds, because it does not rely on fixed waits.
• Can these tools run without a monitor? — Yes. A virtual display such as Xvfb gives them a screen that exists only in memory.
• Why keep a fallback route? — A site can change its page at any time. A second route lets the job finish while you fix the first.
• Is it safe to run these on a shared desktop? — Be careful. Tools that use the kernel input device send input to the whole machine, so prefer a private virtual display.

Tags

#automation #linux #playwright #xdotool #ydotool #dotool #wayland #x11 #browserautomation #devops