Can pip install on Windows ARM64? I tested 20 major packages

numpy 2.5.1, pandas 3.0.5, and scipy 1.18.0 all install directly with Python 3.12 on Windows ARM64. I checked that locally on August 2, 2026. This depends heavily on the pip version and distribution state at the time, so I am putting the date first.

This is probably the point that matters most to someone deciding whether to use an ARM64 machine for work. Python packages with C extensions begin with a build if a compatible wheel has not been published. Install the Visual Studio build tools, fail, and give up: few people want to repeat that familiar old Windows Python flow.

Fetching only wheels

I did not install anything. I used pip download with the platform fixed and checked only whether wheels existed. This avoids dirtying the environment and avoids wondering whether a failed install damaged the current venv.

pip download <package-name> --no-deps --only-binary=:all: `
    --platform win_arm64 --python-version 312 -d .\wh

With --only-binary=:all:, the command fails here if only a source distribution is available. In other words, “failed” can be read as “there is no ARM64 binary for this request.” Whether it can be built is a different question, and I did not test that here. This separation is the point of the run.

pip was 25.0.1 and Python was 3.12.10. Both were native builds under Python312-arm64.

What downloaded and what failed

Eighteen of the 20 packages tested downloaded successfully.

The remaining packages were greenlet 3.5.4, cffi 2.1.0, msgpack 1.2.1, ujson 5.13.0, and pyyaml 6.0.3. Each also arrived with a win_arm64 tag. Eighteen out of 20, or 90%, passed through without trouble.

Only two failed.

ERROR: No matching distribution found for tiktoken

pyarrow stopped with the same wording. It gave up in a few seconds, so it did not make me wait. That is a different kind of failure from waiting for an orjson source build.

cryptography and psutil use different tags

This is a small detail, but two filenames had a different shape when I looked closely. I missed it when I first made the table.

cryptography was cp311-abi3, and psutil was cp37-abi3. These are wheels built for the stable ABI, designed for one file to work from Python 3.11 onward. Even if Python is upgraded to 3.13, these two should reuse the same files.

When predicting what may break after raising Python's minor version, these tags are worth checking. It is a small detail that can matter later.

polars was difficult to interpret

polars downloaded successfully, but what arrived was polars-1.43.2-py3-none-any.whl. From that filename alone, it was not immediately clear where the implementation lived.

py3-none-any means platform-independent. The library is written in Rust, so I do not yet know why a wheel with no binary-looking platform tag resolved for win_arm64. I have not unpacked it to check its contents, so this remains unverified. Whether it actually imports and runs is a separate check.

Where things would get stuck

tiktoken being unavailable mattered in a small but real way. I was trying to write code to count tokens and stopped there. When discussing ARM64, a small dependency like this can suddenly bring you back to reality.

The inventory shows two failed packages, but the impression changes depending on whether those two sit directly in your work path. If one is central to a daily script, that one dependency can abruptly change the usability of an ARM64 environment. You have to consider an alternative implementation, keeping an x64 Python installation beside it, or giving up the feature altogether.

Possible workarounds are counting over HTTP, replacing it with another implementation, or installing x64 Python alongside it and running that part there. I avoided the third option because it duplicates the environment.

The absence of pyarrow affects some pandas features and code that reads Parquet directly. I do not currently have a workaround, so I am leaving it unresolved. If I need to work with Parquet, I will look for another approach, but I have not reached that situation yet.

For clarity, this test checked only whether wheels were distributed. It is different from having installed them locally. The environment currently contains numpy 2.4.1, pandas 3.0.0rc2, Pillow 12.1.0, lxml 6.0.2, and matplotlib 3.10.8. I only confirmed that duckdb, polars, and scipy could be downloaded; I did not install them.

How long this information remains valid

Wheel availability changes day by day. Read this as the result on August 2, 2026. Copying the same command and running it locally gives that day's answer in about two minutes. Conversely, this table is not suitable for keeping as a long-term guarantee.

pip itself displayed a notice that 26.2 was available every time. Changing the version can change resolution behavior, so pip should be kept the same when comparing results. I once saw NumPy resolution change after upgrading pip in June 2026, so I am cautious here. The same package name can tell a different story as soon as the resolver changes.

Finally, this run checked only whether a wheel exists; “it installs and works” is a different question. I did not import and run all 18 successful packages. The five actually installed—numpy, pandas, Pillow, lxml, and matplotlib—have all imported without a problem. The rest remain unverified.