32-Bit and 64-Bit Software Explained

32-bit and 64-bit software labels describe the architecture a program was built to use. They do not automatically tell you whether an app is better, safer, faster, newer, or more trustworthy.

For most modern computers, the practical answer is simple: choose the current 64-bit build when your operating system and processor support it. Choose a 32-bit build only when you are on a 32-bit operating system, need compatibility with a 32-bit add-in or plug-in, or are deliberately running older software in a supported legacy environment.

The label matters most on download pages. A project may list x86, x64, amd64, arm64, 32-bit Windows, 64-bit Windows, Intel Mac, Apple silicon, source archives, installers, portable builds, and package-manager options side by side. The right file is the one that matches your operating system, processor architecture, and compatibility needs.

What 32-bit and 64-bit mean

Bitness usually refers to the architecture a program or operating system targets. In everyday software choices, it is a compatibility signal: the program was built for a 32-bit or 64-bit environment.

A 64-bit operating system can address far more memory than a 32-bit operating system. Microsoft explains the benefit most plainly for Windows users: the advantage of a 64-bit operating system is most visible when the computer has 4 GB of RAM or more and runs several programs at the same time.

For developers, bitness also affects pointer sizes, data models, libraries, compilers, and application binary interfaces. For users, the key question is less abstract: will this file run correctly on this computer, with the drivers, plug-ins, libraries, and files the app needs?

The main download decision

Start with compatibility, then consider memory and support.

If a page lists both 32-bit and 64-bit Windows installers, a current 64-bit Windows machine usually takes the 64-bit installer. If it lists ARM64 separately, do not assume the x64 file is the same thing. If it lists source code, read the source and binary guide before treating that archive as a ready-to-run app.

Operating system and processor must both fit

The processor, operating system, and application need a compatible path. A 64-bit processor can run a 64-bit operating system. A 64-bit operating system can run 64-bit programs built for that platform. Some 64-bit operating systems also run 32-bit programs through compatibility layers.

The reverse is not true in the usual desktop case. A 32-bit operating system cannot run a 64-bit desktop application. If you are still using a 32-bit Windows installation, choose 32-bit software or move to a supported 64-bit operating system when the hardware and migration work allow it.

Microsoft's Windows FAQ says Windows 11 and later are 64-bit only. It also says moving from a 32-bit version of Windows to a 64-bit version requires reformatting the disk, installing the 64-bit version, and reinstalling everything else. Treat that as a migration, not a simple app update.

Why 64-bit software is usually the default

Modern desktop systems are overwhelmingly 64-bit. A 64-bit app can use a larger address space, work with larger data sets, and match the native environment of current operating systems.

That matters for heavy workloads: large images, video projects, engineering files, virtual machines, databases, large archives, scientific data, browser tabs, and development tools. It also matters for plug-ins and extensions inside a host application. A 64-bit host generally needs compatible 64-bit components.

Microsoft's Office guidance gives a practical example. The 64-bit version of Microsoft 365 is the normal install for newer versions unless the user selects otherwise, and Microsoft recommends 64-bit Office for large data sets, large media, very large project files, and 64-bit solution development.

Still, 64-bit does not guarantee speed. Some programs do not need more memory. Some 32-bit programs run acceptably on 64-bit Windows. Performance depends on the app, workload, processor, operating system, drivers, and compatibility layer.

Why 32-bit software still appears

Older software ecosystems do not disappear all at once. A project may keep a 32-bit build for older machines, small utilities, embedded systems, old plug-ins, industrial workflows, games, or business software that has not been ported.

Microsoft's Office guidance also shows why 32-bit can remain useful: some 32-bit COM add-ins, controls, MDE/ADE/ACCDE database files, MAPI applications, and old media codecs may require the 32-bit Office version. In that situation, the 32-bit build is not worse. It is the compatibility match for that workflow.

That said, a 32-bit option on a download page deserves a support check. Is it current? Does the project still publish updates for it? Is it only in the archive? Does the operating system still support running it? A label is not enough.

Windows: 32-bit apps on 64-bit systems

On 64-bit Windows, many 32-bit Windows applications run through WOW64, the Windows compatibility environment for 32-bit apps. Microsoft describes WOW64 as the x86 emulator that lets 32-bit Windows-based applications run on 64-bit Windows.

WOW64 also separates 32-bit and 64-bit application behavior in important ways. Microsoft notes that the system isolates 32-bit applications from 64-bit applications to prevent file and registry collisions, and that a 32-bit process cannot load a 64-bit DLL for execution. A 64-bit process also cannot load a 32-bit DLL for execution.

That boundary explains many confusing support answers. If an old plug-in, driver helper, shell extension, or add-in exists only as 32-bit code, it may not work inside a 64-bit host. If a 32-bit app expects a 32-bit library, pointing it at the 64-bit version of that library is not a fix.

WOW64 is useful, but it is not magic. Microsoft's performance guidance says x86 instructions on x64 processors execute natively and can have similar speed to 32-bit Windows, while overhead and memory behavior vary by processor and workload. The same guidance notes that a 32-bit application under WOW64 generally receives either 2 GB or, when marked large-address-aware, 4 GB of virtual address space.

macOS: 32-bit Mac apps are no longer compatible

Mac users need a different rule. Apple Support says macOS Mojave 10.14 was the last macOS version to run 32-bit Mac apps, and that starting with macOS Catalina 10.15, 32-bit apps are no longer compatible with macOS.

That means a 32-bit Mac application is not a good current download choice for a modern Mac. Look for a current 64-bit build, a universal macOS binary, an Apple silicon build, or the project's current installation instructions.

If an older Mac app shows a message that it needs to be updated, contact the developer or choose a maintained alternative. Do not assume a Windows 32-bit download, an old Mac archive, or source code will solve the compatibility problem.

Linux: architecture labels vary by distribution

Linux download pages often use architecture names instead of only saying 32-bit or 64-bit. Ubuntu's supported-architecture documentation lists amd64 as x86-64, x86_64, x64, AMD64, and Intel 64. It lists arm64 as ARM64, ARMv8, and AArch64. It also lists armhf as ARM32.

Those labels matter because Linux packages are normally built for a specific distribution and architecture. A .deb built for amd64 is not the same target as an arm64 package. A package-manager command may handle the choice for you, but a direct download still requires matching the file to the system.

Ubuntu currently describes i386 as a partial port: a small number of 32-bit Intel/AMD packages are built for legacy binaries and installed on an amd64 host as a supplementary architecture. That is different from saying ordinary users should install a full current 32-bit desktop system.

When in doubt, follow the distribution or project instructions. The package manager guide explains why repository policy, architecture, dependencies, and updates are part of the same choice.

ARM64 is not the same as ordinary 64-bit x64

The phrase 64-bit can hide more than one architecture. x64, x86-64, AMD64, and Intel 64 are closely related labels for the common 64-bit Intel/AMD desktop target. ARM64 or AArch64 is a different 64-bit architecture.

That distinction matters on Apple silicon Macs, Windows on Arm devices, Raspberry Pi-style systems, and ARM servers. Some operating systems can translate or emulate software built for another architecture. Some cannot. Translation can also affect performance, plug-ins, drivers, and command-line tools.

Use the package the project recommends for your platform. If a project offers both x64 and ARM64 builds, choose the native ARM64 build for an ARM64 system unless the project gives a reason to use translation.

How to tell which one you need

On Windows, Microsoft points users to Settings > System > About. The System type field shows the operating-system type and processor type. That is the first place to check before choosing a Windows architecture download.

On macOS, modern systems require 64-bit Mac apps, and Apple silicon adds a separate Intel-versus-Apple-silicon question. Use the project's Mac download guidance rather than guessing from the file name alone.

On Linux, the distribution, package manager, and command line can expose architecture information. Download pages may use labels such as amd64, x86_64, arm64, aarch64, armhf, or i386. The Linux file command can also identify many binaries by type; its manual shows executable output that includes architecture clues such as ELF 32-bit.

File names can help, but they are not authoritative by themselves. Look for labels near the download button, release notes, package-manager instructions, and the project's supported-platform page.

Common label translations

These labels often appear on download pages:

• x86: Usually 32-bit Intel/AMD software.
• x64, x86_64, AMD64, Intel 64, amd64: Usually 64-bit Intel/AMD software.
• ARM64, AArch64, arm64: 64-bit ARM software.
• armhf, ARM32: 32-bit ARM software in some Linux ecosystems.
• i386, i686: 32-bit Intel/AMD Linux or legacy x86 package labels.
• Universal on macOS: Often a package containing more than one Mac architecture, but read the project notes.

The same word can mean slightly different things by ecosystem. A Windows installer, Linux distribution package, macOS application bundle, portable archive, and source release can all carry architecture labels, but they are not interchangeable artifact types.

Plug-ins, add-ins, drivers, and libraries

Architecture compatibility often fails at the edges of an app, not in the app's main window. A host program may start correctly, then fail when it tries to load a plug-in, add-in, codec, database driver, scanner driver, shell extension, or native library built for the other bitness.

This is why switching one app from 32-bit to 64-bit can affect a workflow. Microsoft Office add-ins are a familiar example, but the same pattern appears in audio plug-ins, image filters, old browser components, database connectors, and native development libraries.

If a workflow depends on extensions, verify those extensions first. Matching the main program is not enough when the supporting components are architecture-specific.

When an old 32-bit build is risky

An old build can be useful for compatibility, recovery, or historical research. It should not be treated as a current recommendation unless the project still supports it.

Risk comes from the surrounding system. A 32-bit build may rely on old libraries, old installers, unsupported operating systems, or abandoned plug-ins. It may not receive the same release attention as the main 64-bit build. It may also be unable to use enough memory for modern files.

For important software, check the current project page, release notes, checksums or signatures where offered, and whether the download is current or archived. The portable versus installer guide covers another part of the same decision: architecture is only one label among installer, portable, package, and source options.

Practical checklist

Before downloading, ask:

• Is your operating system 64-bit, 32-bit, or ARM64?
• Does the project offer a current build for that exact platform?
• Are you choosing an installer, portable build, package-manager path, or source archive?
• Do required plug-ins, add-ins, codecs, drivers, or libraries match the same architecture?
• Is a 32-bit build current, or is it an old archive kept for compatibility?
• Does the software need large files, large memory, or heavy media/data workloads?
• Does the project recommend a different package for Apple silicon, Windows on Arm, or Linux ARM?

If you are unsure and the computer is modern, start with the current 64-bit build for your operating system. Use 32-bit only when the operating system or a known compatibility dependency requires it.

Choose by compatibility first

Think of 32-bit and 64-bit as compatibility labels. They describe what environment the software was built for and which surrounding components it can load.

Choose 64-bit for current systems when the project supports it. Choose 32-bit for a specific legacy need, not because it sounds lighter. Check ARM64 separately. Then confirm the rest of the download choice: installer, portable package, source archive, package manager, supported platform, and current release status.