Skip to content

How to Use uv on Windows ARM64

by Tim Hopper
uv

uv ships a native Windows ARM64 binary, but uv python install 3.13 still installs x86_64 CPython by default on Snapdragon machines. That is deliberate: x86_64 wheels still cover more packages on Windows on ARM, and Windows transparently runs them under emulation. Install the native uv binary first, then choose whether this project should stay on emulated x86_64 or move to a native 3.13-aarch64 interpreter.

Confirm you are on Windows ARM64

Open PowerShell and check the architecture:

$env:PROCESSOR_ARCHITECTURE

On a Snapdragon X Elite or other ARM-based Windows machine, you should see:

ARM64

If you see AMD64, follow How to install uv on Windows instead. The rest of this page only matters on ARM64.

Install the native ARM64 uv binary

The standalone installer detects the host architecture and downloads uv-aarch64-pc-windows-msvc.zip automatically. Run it from PowerShell:

powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex"

Open a fresh PowerShell window so the updated PATH takes effect, then verify:

uv self version

Look for aarch64-pc-windows-msvc in the build triple:

uv 0.11.x (… aarch64-pc-windows-msvc)

If that string says x86_64-pc-windows-msvc, you have the emulated build. Reinstall through the standalone installer to pick up the native one.

Choose between emulated x86_64 and native aarch64 Python

Per Astral issue #12906, uv python install intentionally defaults to x86_64 on Windows ARM64 while ARM64 wheel coverage is still uneven.

To install the default emulated build:

uv python install 3.13

uv records cpython-3.13.x-windows-x86_64-none and runs it through Windows on ARM emulation. Most projects work this way without modification.

To install the native ARM64 build instead, pass an architecture suffix to the version:

uv python install 3.13-aarch64

That resolves to cpython-3.13.x-windows-aarch64-none. Native ARM64 builds exist for Python 3.11 and newer; the python-build-standalone project began publishing them in release 20250630 (linked from Astral issue #386).

To list every Windows ARM64 download uv knows about:

uv python list --all-arches

Without --all-arches, uv python list does not show the aarch64 entries on Windows ARM64.

Use native ARM64 Python for a project

For a one-off command, point uv run at the aarch64 build:

uv run --python 3.13-aarch64 python -c "import platform; print(platform.machine())"

You should see ARM64. If you see AMD64, you have the emulated interpreter and any packages installed under it are x86_64 wheels.

For a whole project, set UV_PYTHON in PowerShell so every uv command in the session uses the native build:

$env:UV_PYTHON = "arm64"
uv sync

UV_PYTHON=arm64 resolves to aarch64 and overrides uv’s Windows-ARM64 default. To make it permanent, set it in the user environment:

[Environment]::SetEnvironmentVariable("UV_PYTHON", "arm64", "User")

Open a new PowerShell window for the change to take effect.

To pin the interpreter for a single project, write the full request into the .python-version file at the project root:

cpython-3.13-windows-aarch64-none

uv run and uv sync honor that pin from then on.

Check whether your dependencies have ARM64 wheels

Native ARM64 only pays off if your dependencies publish win_arm64 wheels. Check before you switch with a dry resolution:

uv pip install --dry-run --python-version 3.13 numpy pandas

uv prints the wheel filenames it would download. Look for win_arm64 in the suffix. As of May 2026:

  • numpy and pandas publish win_arm64 wheels for cp311 through cp314.
  • torch does not publish any win_arm64 wheels. Installing it under a native aarch64 Python falls back to a source build, which usually fails because the build needs the CUDA toolkit and an ARM-compatible C++ compiler.

If a package is missing a win_arm64 wheel, your two options are to keep the project on the emulated x86_64 Python (everything resolves to existing win_amd64 wheels) or to drop the package. uv does not currently fall back across architectures within a single environment; mixing aarch64 and x86_64 wheels in the same .venv is not supported.

Switch architectures cleanly

Changing the project’s Python from x86_64 to aarch64 (or back) invalidates the existing virtual environment. Recreate it:

Remove-Item -Recurse -Force .venv
uv sync

uv sync recreates .venv against the new architecture and re-resolves wheels for that platform. The lockfile entries for cross-platform wheels (any wheel whose filename ends in none-any.whl) carry over; platform-specific wheels resolve fresh.

Frequently asked questions

Will native ARM64 ever be the default?

CPython plans to switch its recommended Windows ARM64 build to native aarch64 with Python 3.15, around October 2026 (per the discuss.python.org thread). Treat uv’s default as unchanged until Astral says otherwise.

What does “tier 2 platform support” mean for uv on Windows ARM64?

Astral’s platform support policy lists Windows ARM64 as a Tier 2 target. uv ships official binaries and they are continuously built, but the test suite isn’t run on Windows ARM64 hosts, so individual edge cases can lag the Tier 1 platforms.

Can the standalone installer install the x86_64 uv build instead?

Yes, but there is little reason to. Wheel compatibility depends on the Python interpreter architecture, not the uv binary, so keep the native ARM64 uv unless you need to test the x86_64 build.

What if I see EXCEPTION_ACCESS_VIOLATION running native ARM64 Python?

This was reported in astral-sh/uv#19189 against uv 0.11.7 on Windows ARM64. Check that issue before assuming the crash is in your project.

Learn More

Last updated on
How to use uv on NixOSHow to use uv to speed up Hatch