# How to Use uv on Windows ARM64


[uv](https://pydevtools.com/handbook/reference/uv.md) 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:

```powershell
$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](https://pydevtools.com/handbook/how-to/how-to-install-uv-on-windows.md) 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
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:

```powershell
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](https://github.com/astral-sh/uv/issues/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:

```powershell
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:

```powershell
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](https://github.com/astral-sh/python-build-standalone/releases/tag/20250630) (linked from Astral issue [#386](https://github.com/astral-sh/python-build-standalone/issues/386)).

To list every Windows ARM64 download uv knows about:

```powershell
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:

```powershell
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:

```powershell
$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:

```powershell
[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:

```powershell
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:

```powershell
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](https://discuss.python.org/t/python-on-windows-arm64/104524)). 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](https://docs.astral.sh/uv/reference/policies/platforms/) 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](https://github.com/astral-sh/uv/issues/19189) against uv 0.11.7 on Windows ARM64. Check that issue before assuming the crash is in your project.

## Learn More

- [How to install uv on Windows](https://pydevtools.com/handbook/how-to/how-to-install-uv-on-windows.md) covers the standalone installer, WinGet, and Scoop on x86_64 Windows.
- [How to install Python with uv](https://pydevtools.com/handbook/how-to/how-to-install-python-with-uv.md) walks through `uv python install` on every platform.
- [What are wheel variants?](https://pydevtools.com/handbook/explanation/what-are-wheel-variants.md) explains why packaging hardware-specific builds is hard.
- [uv platform support policy](https://docs.astral.sh/uv/reference/policies/platforms/) lists every architecture uv targets and the support tier for each.
- [Python on Windows ARM64 (CPython discussion)](https://discuss.python.org/t/python-on-windows-arm64/104524) is the upstream thread on switching the recommended default to native ARM64.