Not a FAQ — just the reasoning behind Windows on ARM and why compatibility isn't as simple as "it works" or "it doesn't."
Most Windows PCs, for the last few decades, have used processors built on what's called the x86 architecture — the design Intel and AMD chips share. ARM processors are built differently, around a design that prioritizes power efficiency over raw clock speed. It's the same family of chip design that's powered phones and tablets for years, which is exactly why those devices can run all day on a small battery without a fan.
Windows on ARM brings that same processor design to laptops. The appeal is straightforward: longer battery life, quieter operation (often no fan at all), and less heat — without asking you to give up a full desktop operating system.
Some applications — particularly VPN clients, endpoint security software, virtualization tools, gaming anti-cheat software, and hardware utilities — work more closely with Windows than typical productivity applications. Because they often depend on specialized drivers or other low-level system components, compatibility may be more complex and can evolve as vendors release updates. That's one reason CheckMyARM evaluates both applications and devices when building your compatibility picture.
Software is compiled — translated from source code into instructions a specific processor understands. An application built for x86 contains x86 instructions; an ARM processor doesn't natively speak that language.
Windows solves most of this with emulation: it translates x86 instructions to ARM on the fly, and for the large majority of everyday applications, that translation is good enough that you'd barely notice. Where things get harder is lower-level software — certain drivers, anti-cheat systems, virtualization tools, and other code that talks directly to hardware or the operating system kernel. Emulation has a harder time there, and some of it simply doesn't run until the developer ships a version built specifically for ARM.
Compatibility isn't a fixed, one-time fact — it's a moving target, and mostly in a good direction. Developers ship native ARM64 versions of their apps over time. Microsoft improves its emulation layer with each Windows update. Hardware vendors catch up on ARM drivers for printers, docks, and other devices.
That means an app that only runs emulated today might run natively in six months — which is exactly why CheckMyARM treats its database as something to keep revisiting, not a snapshot to take once and consider finished.
There are hundreds of thousands of Windows applications in active use, built by everyone from large software companies to a single developer maintaining a niche tool on the side. Most of them aren't centrally registered anywhere. New versions ship constantly, and compatibility can depend on the exact version, how it's configured, and what other hardware or software it's interacting with.
No single organization — including Microsoft — has visibility into all of that at once. A complete, always-current, authoritative list isn't something anyone can simply publish; it has to be assembled and continually rechecked from many angles.
Because of that gap, firsthand experience is often the fastest way to find out how something actually behaves. Someone who's already running a particular app on Windows on ARM knows more about it in that moment than any database does.
CheckMyARM combines automated sources with real reports from real people — and a small group of volunteer Researchers who dig into the harder, ambiguous cases — because compatibility knowledge genuinely gets better the more people contribute what they've found. See the About page for how that community model actually works.
None of this is meant to talk you into anything — just to explain why "will my stuff work?" doesn't have a simple yes-or-no answer, and why a real scan of your real PC is more useful than a guess. For the reasoning behind how CheckMyARM turns that scan into an actual recommendation, see How CheckMyARM Thinks.