Uninstall Python and Anaconda on a Mac without breaking anything

To uninstall Python on a Mac, first find out which Python you mean. Most Macs used for programming have several: one that came with Apple's developer tools, and others from python.org, Homebrew, pyenv, uv or Anaconda. Each lives in different folders, and each comes off a different way.

The one to leave alone is Apple's. The python3 command in /usr/bin belongs to Xcode or the Command Line Tools, it sits on macOS's read-only system volume, and other software expects to find it. Everything else can go, once you know what still depends on it.

In short: python.org's Python comes off in Finder, from three places. Homebrew's comes off with Homebrew, which refuses while other packages need it. pyenv and uv keep each version in a folder of its own. Anaconda and Miniconda come with an uninstall script, and otherwise come off as one folder plus a few hidden files.

Before you remove anything, check what's built on it. Virtual environments, command-line tools, Jupyter kernels and editor settings each point at one particular Python, and they stop working when it goes.

Which Pythons can a Mac have?

Python's own documentation lists several ways to get Python on a Mac, and none of them replaces another. They sit side by side, and which one runs when you type python3 depends on the order of folders your shell searches.

Where it came from	Where it lives	How it comes off
Apple's developer tools	/usr/bin/python3, inside Xcode or /Library/Developer/CommandLineTools	It doesn't; it's part of the developer tools
The python.org installer	/Library/Frameworks/Python.framework and /Applications/Python 3.x	Finder, from three places
Homebrew	/opt/homebrew/Cellar on Apple silicon, /usr/local/Cellar on Intel	Homebrew's uninstall
pyenv	~/.pyenv/versions	pyenv, or Finder
uv	~/.local/share/uv/python	uv, or Finder
Anaconda, Miniconda, Miniforge	~/anaconda3, /opt/anaconda3, ~/miniconda3, ~/miniforge3	Its uninstall script, or Finder plus hidden files
mise and asdf	~/.local/share/mise/installs, ~/.asdf/installs	The version manager's own commands

Why does a Mac end up with several Pythons?

Each tool installs the Python it needs without asking about the others. Homebrew adds one the first time you install a package written in Python. uv downloads one when a project asks for a version you don't have. A tutorial may have sent you to python.org, and a data science course to Anaconda.

On the Mac this post was researched on, running macOS 27, there were four: Apple's Python 3.9 from Xcode, Homebrew's Python 3.14, and two versions uv had downloaded, 3.11 and 3.12. Homebrew's had come in as a dependency of other tools, not because anyone asked for it.

Is the Python that came with my Mac Apple's own?

Not anymore. Apple's release notes for macOS Monterey 12.3 say Python 2.7 was removed from macOS in that update, and macOS hasn't included a Python of its own since.

What's left is a python3 command in /usr/bin that runs the Python included with Xcode or the Command Line Tools. If neither is installed, typing python3 offers to install the Command Line Tools. A current Mac has no python command at all, only python3.

With Xcode 27 on macOS 27, that Python is version 3.9. Python's documentation calls it usually older and incomplete, provided by and for Apple's developer tools. It isn't meant to be the Python for your projects.

How to find out which Pythons you have

You can do all of this in Finder. Choose Go › Go to Folder, type a path from the table above, and press Return. Go to Folder also opens hidden folders, such as the ones in your home folder whose names start with a period. If a path doesn't exist, Finder says so and you can move on.

Where should you look first?

• Applications: a folder named Python with a version number, such as Python 3.14, means python.org. An app called Anaconda-Navigator means Anaconda Distribution.
• /Library/Frameworks/Python.framework/Versions: one folder for each python.org version.
• /opt/homebrew/Cellar, or /usr/local/Cellar on an Intel Mac: folders named python@ and a version, such as python@3.14, are Homebrew's.
• Your home folder: folders called anaconda3, miniconda3 or miniforge3 are conda installations. Anaconda's graphical installer puts its folder in /opt/anaconda3 instead.
• ~/.pyenv/versions and ~/.local/share/uv/python: one folder for each version pyenv or uv installed.

Select any folder and choose File › Get Info to see its size. That tells you which removals are worth the effort.

Which one runs when you type python3?

The first one your shell finds. Your shell looks through a list of folders in order, and installers move their own folder to the front by adding lines to a hidden settings file in your home folder.

Apple's support article on shells explains the files: zsh, the default shell since macOS Catalina, reads .zprofile when you log in and .zshrc for each new Terminal window. bash uses .bash_profile. Installers add their lines to one of these.

Each installer's lines put its own folder in front, so the last lines your shell reads usually win. Removing that Python hands python3 to the next one in line, which may be an older version, or Apple's.

What's in the Library/Python folder?

A folder you may find without having put anything there. Python's documentation says that a Python built as a framework, as Apple's and python.org's are, keeps packages you install with pip's user option in ~/Library/Python, in a folder for each version.

On the Mac this post was researched on, ~/Library/Python/3.9 held 659 MB of packages installed for Apple's Python 3.9, including large machine learning libraries. Removing a Python never removes this folder, and it's easy to forget it exists.

Why you should never remove the system's Python

This is the one firm rule. Every other Python on your Mac is yours to remove; this one isn't.

Is it safe to delete /usr/bin/python3?

No, and macOS won't let you. /usr/bin is on macOS's signed, read-only system volume, so its files can't be changed even with an administrator's password.

Python's documentation is blunt about the Python behind it: you should "never modify or attempt to delete this installation", because Apple controls it and both Apple's software and other developers' software use it.

Can you remove the Python that Xcode installed?

Only by removing Xcode or the Command Line Tools. Apple documents how to remove the Command Line Tools package, but that takes git, the compilers and every other developer tool with it. Python is a small part: on the Mac measured here, Xcode's copy took about 23 MB.

You don't need to remove it to stop using it. Python's documentation notes that a python.org Python and Apple's can coexist, and the default installer options make the new one run instead.

What about Python 2.7 on an older Mac?

Macs still on macOS Monterey 12.2 or earlier have Apple's Python 2.7 in the System folder. It's part of macOS there, protected the same way, and the 12.3 update removed it.

A Python 2.7 you installed yourself from python.org is different. It lives in /Library/Frameworks and comes off like any other python.org version, below.

Uninstall Python on a Mac when it came from python.org

The python.org installer asks for an administrator's password, because it installs Python for every user of the Mac. Python's documentation lists what it puts in place, and says that to uninstall Python you remove those three things.

What did the python.org installer put on your Mac?

• A folder in Applications named after the version, such as Python 3.14, with IDLE, Python Launcher, a read-me, and two small scripts: Install Certificates and Update Shell Profile.
• The framework, in /Library/Frameworks/Python.framework, which holds Python itself and its standard library. Each version has its own folder in Versions, and packages you install with that version's pip go inside it too.
• Links in /usr/local/bin, named python3, pip3, idle3, pydoc3 and so on, with and without the version number.

Recent installers can also add a free-threaded build of Python, as a second framework called PythonT.framework next to the first. Its links end in a t, such as python3.14t. If you find it, it comes off the same way.

How do you remove it in Finder?

1. Quit IDLE, Python Launcher and anything else using that Python, including Terminal windows.
2. In Applications, move the folder for that version, such as Python 3.14, to the Trash.
3. Choose Go › Go to Folder, enter /Library/Frameworks/Python.framework/Versions and press Return. Move the folder named after the version to the Trash, and enter an administrator's password when asked.
4. If that was the only version, move the whole Python.framework folder in /Library/Frameworks to the Trash instead, and PythonT.framework if it's there.
5. Go to /usr/local/bin. Finder treats the links there like aliases: select one and choose File › Show Original to see where it points. Move to the Trash the links that point into the version you removed.

Leave the Trash full for now. You'll empty it once you've checked the Pythons you kept still work.

Which links in /usr/local/bin are safe to remove?

Only those that point into the python.org framework for the version you removed. On an Intel Mac, Homebrew keeps its own links in the same folder, including its own python3, and other tools put programs there too.

Never move /usr/local/bin itself, or links you can't trace to the framework. A link whose original no longer exists does nothing, so when in doubt, leave it.

What does the installer leave in your home folder?

The Update Shell Profile step adds lines to .zprofile in your home folder, under a comment that starts with "Setting PATH for Python" and the version. If you use bash, it changes .bash_profile instead. Python's installer script keeps a copy of the file as it was before, ending in .pysave.

The lines are harmless once the framework is gone, but they point at a folder that no longer exists. To remove them, duplicate the file first as a backup, open it in TextEdit, delete only the comment and the PATH lines under it, and save.

Finder hides files whose names start with a period. Press Shift-Command-Period in a Finder window to show them, and press it again to hide them.

Packages you installed with pip's user option stay in ~/Library/Python, in the folder for that version. Remove it too if you won't use that version again.

Is there an uninstaller for python.org's Python?

No. Python's documentation describes no uninstaller, only the three places to remove. Scripts shared online do the same steps in Terminal, but they delete files outright instead of using the Trash, so a wrong path can't be undone. The Finder route takes a few more minutes and keeps every step reversible.

Removing Homebrew's Python

Homebrew's Python is the one you're least likely to have installed on purpose, and the one most likely to have other software depending on it.

Why does Homebrew keep a Python?

Because packages written in Python need one. Homebrew's documentation says that a package which declares a Python dependency is built for that particular Homebrew Python version, and Homebrew keeps the Python installed while that package is.

On the Mac this post was researched on, Homebrew's Python 3.14 was there only because three other installed tools, all written in Python, needed it. Its own folder in the Cellar took 86 MB.

How do you uninstall Homebrew's Python?

With Homebrew. It's a command-line tool, so there's no app or menu for this. Its uninstall removes the package's folder from the Cellar along with the links it made.

If any installed package still needs that Python, Homebrew refuses and names the packages. It offers a way to force the removal anyway, which leaves those packages unable to start. Uninstall them first, or keep the Python.

Homebrew also has a command that removes packages it installed only as dependencies, once nothing needs them anymore. That's often how a Homebrew Python goes: you uninstall the last tool that needed it, then let Homebrew tidy up.

Can you delete Homebrew's Python folder in Finder?

Don't. The catalog's entry for the Homebrew Cellar rates it Review first and leaves removal to Homebrew. Deleting a folder there leaves Homebrew's links pointing at nothing, and the packages that needed it fail with confusing errors.

Old versions are a different matter: Homebrew removes them by itself after upgrades and in its regular cleanup. The Homebrew cleanup post explains what that cleanup removes.

What happens to environments built on Homebrew's Python?

They point at it. When Homebrew moves to a new Python version and the old one goes, environments made with the old one stop working. Homebrew's documentation suggests a separate version manager for projects that need a Python independent of Homebrew's upgrades.

Removing Python versions from pyenv, uv and other version managers

Version managers keep each Python in a folder of its own, so removing one version is simple. What's harder is knowing which environments and tools were built on it. The post on old Python environments goes through that check in detail.

How do you remove a pyenv version, or pyenv itself?

pyenv has its own uninstall command, and its documentation also says you can simply delete a version's folder. In Finder, go to ~/.pyenv/versions and move the folder named after the version to the Trash.

pyenv's documentation adds one catch: its uninstall command also removes environments the pyenv-virtualenv plug-in linked to that version, and deleting the folder doesn't. If you use the plug-in, remove those environments' short links in the same folder.

To remove pyenv completely, its documentation says to remove every pyenv line from your shell's startup file first, then its root folder, ~/.pyenv, which deletes every Python it installed. If you installed pyenv with Homebrew, uninstall it there last. Skip the first step and every new Terminal window complains that pyenv can't be found.

The catalog rates Python versions installed with pyenv as Review first, because getting one back means building Python from source again, and packages installed into it are gone.

How do you remove uv's Python versions, or uv itself?

uv keeps each Python it downloads in ~/.local/share/uv/python. When you install one with uv's install command, it also adds a link such as python3.12 to ~/.local/bin. uv has its own uninstall command for versions; moving a version's folder to the Trash in Finder works too.

The catalog rates Python versions installed by uv as Usually safe. uv downloads a version again when a project needs it, but it doesn't rebuild what was made with it.

On the Mac this post was researched on, a command-line tool installed with uv, 126 MB, ran on uv's Python 3.11. Removing 3.11 would have broken the tool, and nothing in the tool's name hinted at it.

uv's documentation lists the steps to remove uv entirely: clear its cache with uv's own command, remove its Python and tool folders, then remove the uv and uvx programs from ~/.local/bin. uv expects to manage its cache itself, so that first step stays a uv command.

What about pipx apps?

pipx installs each Python command-line app in its own environment, built on the Python pipx was using at the time. Remove that Python, and those apps stop starting. The catalog rates Apps installed with pipx as Review first, because each one is an app you installed.

What about mise and asdf?

They manage many languages, not only Python, and each keeps records of what it installed. The catalog explains mise tool versions and asdf tool versions, and leaves their removal to the tools' own commands, which remove one version at a time. The post on Ruby versions and gems covers what they keep for Ruby.

Version manager	Where versions live	Remove one version	What it costs
pyenv	~/.pyenv/versions	pyenv's uninstall, or its folder in Finder	A rebuild from source to get it back
uv	~/.local/share/uv/python	uv's uninstall, or its folder in Finder	Tools and environments built on it break
mise	~/.local/share/mise/installs	mise's own commands	Projects asking for it can't use it
asdf	~/.asdf/installs	asdf's own commands	Projects asking for it can't use it
pipx	~/.local/pipx/venvs or ~/Library/Application Support/pipx/venvs	pipx's uninstall	The app's commands stop working

How to uninstall Anaconda or Miniconda on a Mac

Anaconda is usually the largest Python on a Mac. Anaconda's system requirements ask for at least 5 GB of disk space to install Anaconda Distribution, and its environments add more inside the same folder.

Anaconda Distribution, Miniconda or Miniforge?

All three install conda and a Python, in one folder. They differ in size, in who makes them and in how they're removed.

Install	Usual folder	Space to install	Uninstall script
Anaconda Distribution, graphical installer	/opt/anaconda3, for all users	At least 5 GB	Included since version 2025.06
Anaconda Distribution, Terminal installer	~/anaconda3	At least 5 GB	Included since version 2025.06
Miniconda	~/miniconda3 or /opt/miniconda3	At least 400 MB	Included since version 24.11.1
Miniforge, from conda-forge	~/miniforge3	Not stated	Its read-me lists manual steps

What does Anaconda's own uninstaller do?

Anaconda's documentation describes an uninstall script inside the installation folder, run in Terminal. It removes the installation, and optionally conda's caches, its configuration files and its user data. There's no app or menu version of it on a Mac.

Installations from before those versions have no script. For them, Anaconda's documentation describes a manual uninstall: undo conda's changes to your shell's startup files, remove the installation folder, and optionally remove three hidden items in your home folder. That's the route you can follow in Finder.

Before you start: what to keep

If you might reinstall, save the recipe of each environment you care about. Anaconda Navigator's Backup button and Anaconda Desktop's Export do it without Terminal, as the post on old Python environments explains.

Anaconda's documentation also recommends removing environments you created outside the installation folder before you uninstall, because they won't go with it. The hidden file ~/.conda/environments.txt lists every environment conda knows, one folder per line; open it in TextEdit to see where they are.

Your notebooks and data files are only at risk if you saved them inside the installation folder. Look before you move it.

How do you remove Anaconda in Finder?

1. Quit Anaconda Navigator, Jupyter, Spyder and any Terminal window where conda is active.
2. Open .zshrc in your home folder in TextEdit, after duplicating it as a backup. Delete everything from the line # >>> conda initialize >>> to the line # <<< conda initialize <<<, both included, and save. If you used bash, do the same in .bash_profile.
3. Move the installation folder to the Trash: anaconda3 in your home folder, or /opt/anaconda3, which asks for an administrator's password.
4. If Anaconda-Navigator is still in Applications, move it to the Trash too. Anaconda's documentation warns that uninstalling can leave shortcuts behind.
5. Optionally, move the hidden .condarc, .conda and .continuum from your home folder to the Trash. Keep .condarc if you'll reinstall and want your conda settings back.
6. Open a new Terminal window. The (base) at the start of the prompt should be gone.

The same steps work for Miniconda, with miniconda3 in place of anaconda3. Miniforge's read-me lists the same three parts: conda's lines in your shell files, its folder, and the .condarc file and .conda folder.

Can you remove just Anaconda Navigator?

Yes. Anaconda's documentation describes it as removing one conda package from the base environment, with conda in Terminal. Conda, your environments and your packages stay.

Why does emptying the Trash take so long afterwards?

An Anaconda folder holds a very large number of small files, and emptying the Trash has to erase each one. Let it run. Empty it only after a day or two of normal use, so anything you missed can still be put back.

What removing a Python breaks

Removing a Python itself is quick. What takes thought is everything that was built on that one Python and still points at it.

What's built on it	Where it records the Python	After the Python goes	The fix
A project's virtual environment	The home line of its pyvenv.cfg	It can't start	Create it again from the project's requirements
A conda environment	Inside the installation, or listed in ~/.conda/environments.txt	Removed with the installation, unless it was elsewhere	Recreate it from a saved recipe
pipx and uv tools	Their own environments	Their commands stop working	Install them again with another Python
A Jupyter kernel	The kernel's settings	It fails to start	Remove the kernel, or register another Python
Your editor	Each project's chosen interpreter	It asks you to pick one again	Choose another Python
Homebrew packages written in Python	Homebrew's dependency records	Homebrew won't remove the Python	Uninstall the packages first, or keep it
Shell settings	.zprofile, .zshrc, .bash_profile	Errors or dead folders in new Terminal windows	Remove the installer's lines

How do you tell which Python an environment uses?

Open the environment's folder, select pyvenv.cfg and press the Space bar to Quick Look it. The home line names the folder of the Python it was built from. If that's the Python you're removing, the environment goes with it, in effect.

Virtual environments are meant to be thrown away and made again from a requirements or lock file, so that's usually fine. The catalog rates a Python virtual environment (.venv) as Usually safe for that reason.

What about scripts that name a Python?

A script whose first line names a particular Python, such as one in /Library/Frameworks or ~/anaconda3, stops running when that Python goes. Scheduled jobs and automations that call a Python by its full path break the same way. Search your scripts for the folder's name before you remove it.

How much space does removing a Python free?

Less than you might think, unless it's Anaconda. A Python is tens of megabytes. The space is in what's around it: Anaconda's packages, the environments built on each Python, and the caches pip, uv and conda keep.

• Anaconda Distribution, to install5,000 MB
• Packages for Apple's Python, one Mac659 MB
• Miniconda, to install400 MB
• Homebrew's Python 3.1486 MB
• One Python version from uv56–63 MB · Usually safe
• Apple's Python inside Xcode 2723 MB

Anaconda and Miniconda figures are the minimums in Anaconda's system requirements. The rest were measured on one Mac running macOS 27 for this post; yours will differ.

If space is what you're after, the caches are often a better first target than the Pythons themselves. The Python caches post covers pip, uv and Poetry.

Uninstalling Python safely: the order that avoids surprises

Doing things in this order means nothing you keep breaks without warning.

Step by step

1. List what you have, with the folders in the first table.
2. Pick what stays. Most people keep Apple's Python, which they can't remove anyway, and one Python they actually use.
3. Check what's built on each one you're removing: environments, tools, Homebrew packages and scripts.
4. Save recipes of conda environments you might want again.
5. Remove from the top down: apps and tools that use a Python first, then the Python, then its lines in your shell files.
6. Open a new Terminal window and check the Python you kept is the one that runs.
7. Empty the Trash after a day or two of normal use.

A worked example

Say you have python.org's Python 3.12 from an old tutorial, Homebrew's Python 3.14 that came with a download tool, and Miniconda from a course you finished.

Python 3.12 has no environments left, so its Applications folder, its folder in Versions and its links in /usr/local/bin go to the Trash, along with its lines in .zprofile.

Homebrew's Python stays, because the download tool still needs it. Miniconda's folder, its block in .zshrc and its hidden files go too, once you've saved the one environment you might reuse.

Afterwards, python3 in a new Terminal window runs Homebrew's 3.14. Apple's 3.9 is still there, untouched, for Xcode.

Mistakes to avoid

Most problems after uninstalling Python come from removing a little too much.

Removing Apple's python3 or anything in System folders

You can't remove /usr/bin/python3, and trying to get around macOS's protection to do it weakens your Mac's security for no gain. Leave Apple's Python and the Command Line Tools alone.

Deleting whole shared folders

/usr/local/bin, ~/.local/bin and ~/.local/share hold other programs too. On the Mac this post was researched on, ~/.local/bin held several unrelated command-line tools besides uv's. Remove only the items that belong to the Python you're removing.

Forcing Homebrew to remove a Python that's still needed

Homebrew refuses for a reason. Forcing it leaves every package that needed that Python broken until you reinstall it.

Pasting removal commands from the web

Commands that delete files skip the Trash, so a typo in a path can't be undone. Everything in this post works in Finder, TextEdit and the tools' own apps, except where a tool only offers a command, and this post says where.

Emptying the Trash straight away

If a project or tool breaks a day later, File › Put Back fixes it while the Trash is still full. After it's emptied, only a backup can.

How the app does it

Wombit explains Python's folders like everything else on the disk. Select one in the map or the list, and the inspector says what it is, how safe it is to remove and what removing it costs, from the catalog's entry. It reads only names, sizes and dates, and file names and paths never leave your Mac.

Cleanup lists them by level:

• uv's Python versions and project virtual environments are Usually safe and wait for you to check them.
• pyenv versions and pipx apps are Review first.
• The Homebrew Cellar, mise's versions and asdf's versions are Review first too, but they're explained with the tool's own way to remove them. The app doesn't move them.
• uv's cache and conda's package cache are Safe and start checked.

For the two caches, the app runs the tool's own cleanup instead of deleting files, after the review sheet. What a command removes can't be put back, and the sheet says so. conda's cleanup leaves every package your environments use, so it frees less than the folder's size.

Folders no catalog entry explains, such as python.org's framework or an Anaconda installation as a whole, are never offered for removal. On a Mac with Apple Intelligence, the inspector can give a Best guess at what one is, labelled as a guess. Remove those the way this post describes.

• ~/.local/share/uv/python/*

  Python versions installed by uv

  A version of Python uv downloaded, used by the projects, tools and environments uv manages.

  Usually safe · Moves it to the Trash

• ~/.pyenv/versions/*

  Python versions installed with pyenv

  A version of Python installed with pyenv, along with the packages installed into it.

  Review first · Moves it to the Trash

• ~/.local/pipx/venvs/*

  Apps installed with pipx

  A Python command-line app installed with pipx, in its own separate environment.

  Review first · Moves it to the Trash

• /opt/homebrew/Cellar

  Homebrew Cellar

  Command-line tools and libraries installed with Homebrew, in one folder for each package and version.

  Review first · Explained only: never removed

• ~/.cache/uv

  uv cache

  Python packages, wheels and temporary tool environments that uv downloaded or built.

  Safe · Runs uv cache clean

• ~/{miniconda3,miniforge3,anaconda3}/pkgs

  conda package cache

  Packages conda downloaded and unpacked, kept to create and update your environments.

  Safe · Runs conda clean --all --yes

Seeing all of this is free. Removing it is PRO, one $4.99 payment with lifetime access. Every Pro tool's review is free to open, so you see what would go and why before you buy.