Building a Native ARM64 Tor Browser on Windows

For years, discussions about Windows on ARM have tended to follow a familiar pattern.

The hardware is impressive.

Battery life is excellent.

Performance is promising.

But eventually someone asks:

Sure, but can it do real work?

I decided to test that question with a project that sits at the intersection of networking, cryptography, open source software, and browser engineering: building a fully native ARM64 Tor Browser stack on Windows.

What started as a curiosity turned into something more interesting.

Not because it was difficult.

Because it was surprisingly normal.

The Goal

The objective was simple:

Build a native ARM64 version of Tor Browser and pair it with a native ARM64 build of the Tor daemon itself.

The browser wasn’t the challenge.

Modern Firefox and Tor Browser development has come a long way on ARM64.

The bigger question was Tor.

If the browser was native but the networking and cryptographic backend was still running under x64 emulation, how much performance was being left on the table?

There was only one way to find out.

The Journey Begins

I set up an ARM64 build environment using MSYS2’s CLANGARM64 toolchain and began working through the Tor build process.

Initially, things went badly.

Configure scripts failed.

Autotools generated seemingly impossible shell errors.

Builds broke in confusing ways.

For a while I started to suspect I had discovered an upstream build bug.

Looking back, that assumption was wrong.

The actual issue was far less exciting.

I had mixed development environments.

Part of the workflow was using Git for Windows while another part was using Git from inside the MSYS2 ARM64 environment. Once I standardized the entire workflow inside the ARM64 toolchain and performed a clean reset, many of the mysterious failures vanished.

That turned out to be a recurring theme throughout the project.

An Important Observation

One of the most interesting findings from this experiment was not what failed.

It was why things failed.

None of the major obstacles turned out to be ARM64 compatibility issues.

The problems were:

• build environment configuration
• runtime path configuration
• packaging assumptions
• developer tooling mistakes

The problems were not:

• ARM64 incompatibility
• Windows on ARM limitations
• Tor source code issues
• Firefox source code issues

Once the environment was correct, the software generally behaved exactly as it was supposed to.

That’s a subtle but important distinction.

A platform transitions from experimental to legitimate when the bugs stop being architecture problems and start being ordinary developer problems.

Building Tor

Eventually the build succeeded.

The resulting executable identified itself as:

PE32+ executable for MS Windows 6.00 (console), ARM64

Running it directly worked immediately:

Tor version 0.4.9.12
Tor compiled with clang version 22.1.7

At this point there was no emulation involved.

No x64 compatibility layer.

Just native ARM64 code.

The Missing Piece

When I launched my ARM64 Tor Browser build, it still refused to connect.

The browser logs eventually revealed the problem.

Tor Browser was looking for:

TorBrowser\Tor\tor.exe

and no such file existed.

This wasn’t an ARM64 issue.

It wasn’t a browser issue.

It wasn’t a Tor issue.

The browser simply expected a Tor executable that had never been placed where it expected to find one.

After copying the freshly-built ARM64 Tor binary into the expected location, everything changed.

The browser started the daemon.

The control port connected.

Bootstrap began.

The browser connected to the Tor network successfully.

The entire stack was now running natively on Windows ARM64.

Performance

I did not begin this project intending to benchmark performance.

My goal was simply to make the stack work.

However, after everything was running, one thing became immediately noticeable:

It felt faster.

Pages appeared more responsive.

Navigation felt smoother.

Media-heavy websites loaded more comfortably.

As a quick real-world comparison, I used CNN as a rough workload because it combines:

• heavy JavaScript
• video content
• animations
• advertising frameworks
• multiple network requests

The native ARM64 build consistently felt more responsive than the version relying on x64-emulated components.

I also observed lower CPU utilization during testing, though I have not yet collected enough telemetry to quantify the reduction with confidence.

The subjective difference was noticeable enough that I began recording video and collecting timestamps to investigate further.

What I Have Not Proven

I have not proven that native ARM64 Tor is a specific percentage faster.

I do not yet have a comprehensive benchmarking suite.

Bootstrap timing is influenced by relay selection, network conditions, and other variables that make rigorous comparison difficult without automation.

At the moment, my data is a mixture of build logs, runtime logs, video recordings, CPU observations, and real-world usage.

That is enough to establish feasibility.

It is not enough to establish definitive performance numbers.

Yet.

What I Did Prove

I did prove something I think is arguably more important.

A fully native Windows ARM64 Tor Browser stack is possible.

Not theoretically.

Not in a simulator.

Not in a laboratory.

On real hardware.

Connecting to the real Tor network.

Browsing the modern web.

A Bigger Takeaway

Going into this project, part of me was still carrying an assumption that Windows on ARM would eventually hit a wall.

Instead, the most surprising result was how ordinary the process became.

Once the environment was configured correctly, the workflow looked familiar:

configure
build
debug
run
repeat

The roadblocks were not architectural.

They were operational.

The kind of problems developers encounter on every platform.

That’s perhaps the strongest endorsement of Microsoft’s and Qualcomm’s work on Copilot+ PCs that I can offer.

Not that everything worked perfectly.

But that when something broke, it wasn’t because ARM64 couldn’t do the job.

Where Things Go From Here

The next logical step is automated performance testing.

I’d love to see:

• Tor bootstrap benchmarks
• page load benchmarks
• CPU utilization comparisons
• memory usage comparisons
• battery-life testing

Those measurements will tell a much more complete story than subjective impressions alone.

For now, I’ve answered the original question.

Can a fully native ARM64 Tor Browser stack run on Windows?

Yes.

And perhaps more importantly:

The reasons developers believe they need an x86 laptop continue to shrink.

Whether ARM ultimately replaces x86 remains an open question.

What seems increasingly clear is that many of the old arguments against Windows on ARM are becoming harder to defend through actual experience.

And in the spirit of empirical investigation, that’s a conclusion worth paying attention to.