.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
The official Miniconda download page is a bare directory index, hundreds of files, no guidance, which is presumably why "miniconda download" gets searched a couple thousand times a month by people who found the page and closed it again. It rewards a few minutes of orientation, though. Those filenames encode everything from Python version pinning to installers that still run on a 2014 CentOS box, and once you can read them the page stops being intimidating.
How the Miniconda download page works
Everything lives at repo.anaconda.com/miniconda/, a flat listing with four columns: filename, size, last modified date and each file's SHA256 hash. Newest releases sit at the top, and scrolling down walks you back through years of releases, all the way to 2015. The old files aren't clutter, they're the compatibility archive, and there's a section on when you'd want one below.
Anaconda's marketing site has a separate download flow with an email prompt in front of it. Skip it. The repo index is the canonical source, no signup involved, and it's what every script and Dockerfile in the wild pulls from anyway.
Latest vs versioned installers
The files at the top split into two families. The latest family carries stable filenames that never change but always contain the newest release:
Miniconda3-latest-Linux-x86_64.sh
Miniconda3-latest-MacOSX-arm64.sh
Miniconda3-latest-Windows-x86_64.exeThe versioned family bakes the release into the name, Miniconda3-py314_26.5.3-2-Linux-x86_64.sh for example. Today they're the same artifact; over time they behave differently, since the latest link silently becomes a different file at the next release while the versioned one stays frozen forever.
How I split it: interactive installs on my own machines get latest, and anything automated, CI images and provisioning scripts above all, gets a versioned filename with its SHA256 pinned beside it. A build that pulls latest will one day pull a release nobody tested, and in my experience it picks the worst possible week for it. Pinned installer plus pinned hash keeps the build reproducible until you decide otherwise.
What the py314 prefix means
The py314 in Miniconda3-py314_26.5.3-2 is the Python version that lands in the base environment: py314 is Python 3.14, py311 is Python 3.11 and so on. The number after the underscore, 26.5.3-2, is the release of the installer itself, which also tells you which conda it ships.
The current release line (26.5.3-2, July 29, 2026) comes in five Python flavors: 3.14.6, 3.13.14, 3.12.13, 3.11.15 and 3.10.20. A "Miniconda 3.11 installer" in practice means Miniconda3-py311_26.5.3-2-Linux-x86_64.sh or the sibling for your platform. As for the 3 in Miniconda3, that's Python 3, a name held over from the years when a Miniconda2 with Python 2 existed next to it; there's no separate product called Miniconda 3 to go hunting for, every modern installer is Miniconda3-something.
Does the base Python version matter?
Less than people assume. Base is where conda itself lives, and conda should be the only thing living there; real work belongs in environments, and each environment gets whatever Python you request regardless of base. A base on 3.14 will happily build a 3.10 environment for the one legacy project that needs it.
So on a personal machine, take latest and move on. The exception is tooling that imports from base's Python directly, some IDE integrations and in-house scripts do, and there the py-versioned installer matching what that tooling expects is the pragmatic pick. The relationship between base and the environments built on top of it comes up again in the Miniconda install guide for Ubuntu and its Windows counterpart.
