To change the Python version in PyCharm, click the Python Interpreter selector in the status bar and pick an interpreter built on the release you want. If it isn’t listed, add one through Add New Interpreter.
Existing virtual environments are the sticking point. A venv is a base interpreter plus its installed packages, so a venv keeps the Python version it was created with (JetBrains PyCharm help). Moving a project to another release means building a new environment and reinstalling the dependencies from requirements.txt.
JetBrains support told a user the same thing when they asked about going from Python 3.13.3 to 3.13.5. That’s a patch release, and it still needed a fresh environment.
How to Change the Python Version in PyCharm
Click the interpreter name in the status bar, choose one built on the version you want, and let PyCharm re-index the project. A version that isn’t in the list has to be added through Add New Interpreter first.
JetBrains calls the status bar selector the quickest way to switch interpreters (PyCharm help).
- Open the project and click the interpreter name in the status bar.
- Choose a listed interpreter whose label shows the target version, for example Python 3.13.
- If nothing fits, choose Add New Interpreter, then Add Local Interpreter.
- Select the environment type and the base interpreter on the new version.
- Click OK and wait for indexing to finish.
The settings page reaches the same list. Press Ctrl+Alt+S on Windows and Linux, or open PyCharm, then Settings on macOS.
As of the PyCharm 2026.2 help, the page sits under Python, then Interpreter. The 2025.1 documentation still shows it under Project, then Python Interpreter.
Every entry in the list points at a Python executable. For a venv that means venv/bin/python on macOS and Linux, or venv\Scripts\python.exe on Windows.
The Add New Interpreter dialog branches by environment type, and adding an interpreter step by step walks through each branch.
PyCharm marks an interpreter as unsupported once it drops support for that old Python release (JetBrains help). Treat that flag as a reason to move to a newer version.
When the Version You Need Is Not Listed
The list only shows interpreters PyCharm already knows about, so a release that was never installed or configured simply won’t appear.
Download the release from python.org and note the install path, or use pyenv to keep several versions side by side on macOS and Linux. Conda is the odd one out. It builds an environment around a chosen Python version and needs no separate install.
On Windows and macOS, the New Project dialog can download and install a Python version that is missing from the system. Linux doesn’t get that option (JetBrains help). Otherwise, browse to the executable in the base interpreter field and confirm.
One Debian 12 user on PyCharm 2023.1.4 Professional could not create a Python 3.8 venv from the dialog. Building it with python3.8 -m venv and adding it as an existing environment worked straight away (JetBrains community thread).
Pick a release that still gets security fixes. The Python Developer’s Guide schedules end-of-life five years after a version’s first release by default.
Which Method Fits: Switching, Recreating, or Another Environment Manager
If an environment on the target version already exists, just switch to it. A project venv sitting on the wrong base interpreter has to be recreated. And when Conda, Poetry, Pipenv or uv owns the environment, use that manager’s own flow.
Check the interpreter list first. If one entry already carries the target version, switching takes seconds.
| Method | Use when | What changes | Cost |
|---|---|---|---|
| Switch to a listed interpreter | An environment on the target version exists | Project interpreter only | Seconds |
| Recreate the venv | The project venv has the wrong base Python | New venv, fresh package set | One reinstall |
| Conda environment | Conda owns the project environment | New environment with chosen Python | New environment plus reinstall |
| Poetry, Pipenv or uv | The manager owns environment and lockfile | New environment from a new base interpreter or Python version | Reinstall and re-lock |
Only the first row leaves packages alone, because each environment carries its own package set.
The managers differ in more than version handling, so compare venv, Conda and Poetry before choosing for a new project.
System Interpreter or Project Virtual Environment
Skip the system interpreter for project work. It’s the one choice that makes a version change hit every project at once.
A system interpreter needs nothing built, so the switch is instant, and a single install covers quick scripts. The downside is that packages are shared across every project on the machine, and upgrading the system Python changes all of them together.
A project virtual environment gives you isolated, project-specific packages (JetBrains PyCharm help) and can be rebuilt from requirements.txt in a few minutes. It does cost one more folder per project, and a version change means building a new environment.
How to Move an Existing Virtual Environment to a New Python Version
A venv’s Python version is fixed when it is built, since the environment is just a base interpreter plus the packages installed in it (JetBrains PyCharm help). So a move means creating a new environment on the new base interpreter and reinstalling the dependencies.
JetBrains support gave the same answer to a user who wanted to move a venv from Python 3.13.3 to 3.13.5. Recreate the environment on the new base interpreter, then install the project dependencies. Even a patch release counts.
- Save the dependency list from the old environment while it is still active, for example with pip freeze > requirements.txt in the PyCharm terminal.
- Click the interpreter selector, choose Add New Interpreter, then Add Local Interpreter, then Virtualenv.
- Choose a new environment and pick the base interpreter on the target version.
- Set Location to an empty directory (JetBrains requires it to be empty), so rename or remove the old venv folder first.
- Click OK. PyCharm points the project at the new environment.
- Install the saved dependencies into it.
The dialog options for creating a virtual environment in PyCharm include the location and base interpreter fields used in steps 3 and 4.
If a project has no environment at all, PyCharm offers to create one from requirements.txt, and you can keep the suggested options or pick a different base interpreter (JetBrains help).
Delete the old folder only after the new interpreter runs the project cleanly. The details of removing a venv safely differ slightly by operating system.
Copying doesn’t work either. A JetBrains support reply on a PyCharm 2024.1.4 thread pointed out that venvs are not portable, so a venv copied with the project folder to a new machine should be rebuilt there, not reused.
Changing the Version in Conda, Poetry, Pipenv, and uv Environments
Conda and uv take the Python version from a dropdown, while Poetry and Pipenv take a base interpreter. Either way the change builds a new environment, and the old one stays on disk until you remove it.
Conda
Anaconda’s PyCharm guide describes the flow for a project that already exists: open it, click Add Interpreter, create a new environment, and select the Python version from the dropdown.
PyCharm normally detects the conda installation. If it doesn’t, point it at the conda executable (JetBrains help). You can also select an existing conda environment from the list, but that never changes its version. Build a new one when the version has to change.
Poetry and Pipenv
For Poetry, select it as the environment type and choose the base interpreter. If PyCharm cannot find Poetry, the dialog offers Install poetry via pip (JetBrains help).
Poetry also reads the python constraint in pyproject.toml. A base interpreter outside that range produces a “not supported by the project” error, so widen the constraint first.
Pipenv works the same way on the PyCharm side. Select it and choose the base interpreter. Open a project that has a Pipfile and no interpreter, and PyCharm suggests building the environment from it.
Editing python\_version under [requires] in the Pipfile does not rebuild an existing environment. A pypa/pipenv issue reports that pipenv install keeps using the old venv, and Pipenv’s workflow notes give the sequence: pipenv –rm, update [requires], pipenv –python 3.11, then pipenv lock.
Poetry at least complains about a wrong version. Pipenv just ignores it, and that’s the worse failure.
uv
PyCharm 2024.3.2 or later lists uv as an environment type (JetBrains help).
Choose Add Local Interpreter, select uv, then pick the Python version for a new environment. New uv projects also get a generated pyproject.toml.
To check the result, compare the version PyCharm shows with the output of uv python pin. If they differ, select the uv environment again in Settings (pydevtools handbook).
What Happens to Installed Packages After the Switch
Packages belong to the interpreter, so a new interpreter starts with its own list and the old packages stay behind. PyCharm manages packages for one particular interpreter at a time and uses pip by default (JetBrains PyCharm help).
The easiest way to restore them is the prompt. The current JetBrains help describes it: when a project holds a requirements.txt and packages are missing, PyCharm offers Install requirements or Ignore requirements. It runs that check when you open requirements.txt or a Python file against the current interpreter. Pick install, and the list lands in the interpreter you just selected.
Doing it by hand works too. Run pip install -r requirements.txt in the PyCharm terminal with the new environment active, or use the Python Packages tool window to search for and install single packages for the selected interpreter.
For one-off additions, installing packages in PyCharm through the Python Packages window beats typing pip commands.
Regenerate the file afterwards with pip freeze > requirements.txt from the new environment, so it matches the interpreter that now runs the project.
The Inherit packages from base interpreter checkbox in the new virtualenv dialog copies global packages into the environment (JetBrains help). Leave it off. It brings back the shared-package problem a project venv exists to avoid.
When a Package Has No Build for the New Python
NumPy 2.3.2 added wheels for Python 3.14.0rc1 and lists support for Python 3.11 through 3.14 (NumPy release notes, July 2025). NumPy 2.5.0 has since dropped Python 3.11 and supports 3.12 through 3.14 (NumPy release notes).
Read the release notes of your heaviest dependency before the switch. The supported Python range sits near the top.
Libraries also retire old interpreters on a schedule of their own. NEP 29 recommended a 42-month window per Python version, and SPEC 0, which replaced it, recommends 3 years (NumPy issue 24932).
That issue argued that Python 3.9, released on October 5, 2020, could already be dropped under the shorter window. Downgrading hits the same wall from the other side.
When upgrading, confirm that each key library lists the target version. When downgrading, pin older library releases that still support it.
How to Confirm PyCharm Uses the New Version
Compare the status bar label with the output of python –version in the PyCharm terminal, then run a one-line script. All of them should show the target version, and sys.executable should point inside the new environment.
Terminal and Script Checks
The status bar shows the active interpreter at a glance. In the terminal, python –version gives the version, and a short script can print more: import sys, then print(sys.version, sys.executable).
A terminal tab opened before the switch can keep the old environment. JetBrains community replies advise closing the tab and opening a new one, with Activate virtualenv ticked under Settings, Tools, Terminal.
The basics of opening the terminal in PyCharm are covered in a separate guide.
For a stubborn mismatch, the JetBrains troubleshooting page suggests copying the interpreter path from the Show All list. Run the script with that path from a terminal and compare the result with the IDE run.
Run Configurations Can Override the Project Interpreter
Each Python run configuration has its own Python Interpreter field (JetBrains help). When that field names a specific interpreter, changing the project interpreter does not touch it.
Each script you started by running code in PyCharm received a temporary configuration on its first run (JetBrains help). Open Run, Edit Configurations, check the field in every saved one, and reselect the new interpreter where needed.
The project interpreter is whatever the status bar shows. A run configuration’s interpreter is set per configuration, so the two can differ. That mismatch explains an editor that reports one version while a run prints another.
When the Version Change Fails
Failures usually trace back to the path or the packages. The executable at a saved path may be gone, PyCharm may not accept the path as a Python executable, the version may be flagged unsupported, or the packages may sit in the other interpreter.
| Symptom | Cause | Fix |
|---|---|---|
| No Python at a saved path | The install was removed or moved | Reinstall at that path or rebuild the venv |
| Invalid Python SDK | Path points at a wrapper, not the executable | Select the real Python executable |
| Interpreter marked unsupported | PyCharm dropped that old Python version | Use a newer base interpreter |
| ModuleNotFoundError after the switch | Packages live in the other interpreter | Run the new interpreter’s own pip |
One user pointed PyCharm at a bash script that runs sudo python and got Invalid Python SDK, plus a version label of 3.13 for a Python 3.10 install (JetBrains community thread). The path has to lead to the executable itself.
A 2022 Python forum thread shows the missing-path error: a project kept looking for python.exe in a folder after the Python 3.9.0 install there was gone.
The JetBrains troubleshooting page covers the last two rows. Old versions get an unsupported marker in the interpreter list, and a missing package is fixed by running the interpreter path with -m pip install.
Restart PyCharm, or log out and back in, before anything drastic. The Debian 12 thread ended with the dialog working again later, after the user had logged out and back in, and no cause was found.
Python Interpreter in PyCharm FAQ
Does the free version of PyCharm support switching the Python interpreter?
Yes. Switching between local interpreters works without a Pro subscription.
Remote interpreters over SSH, Docker, Docker Compose or WSL need PyCharm Pro (JetBrains help). PyCharm 2025.2 was the last separate Community Edition release. From 2025.3, Community users move to the unified PyCharm, which keeps its core features free (JetBrains).
How do I remove an old interpreter from the list?
Open Interpreter Settings from the Python Interpreter selector, click Show All, choose the entry, and click Remove Interpreter (JetBrains help).
That clears it from the project settings only. Delete the environment folder yourself if you want the disk space back.
Which Python version does the PyCharm console use?
By default, the interpreter defined for the project (JetBrains help). To assign a different one, open Settings, Build, Execution, Deployment, Console, Python Console, and pick from the interpreter list.
That list holds pre-configured interpreters only, so add the new one first. The Configure interpreters link on the same page opens the interpreter settings (JetBrains help).
Can I reuse a virtual environment in another project?
Yes. JetBrains notes that a created virtual environment can serve other projects when you select it as an existing environment.
Keep Associate this virtual environment with the current project unticked if it should stay available elsewhere. When ticked, the interpreter belongs to the current project only.
Can two projects run on different Python versions?
Yes. The interpreter is configured per project, so one project can stay on an older release while another moves to a newer one.
Each project keeps its own interpreter entry and its own package set.
Making the Next Python Interpreter Change Repeatable
A Python interpreter in PyCharm is cheap to change when the project treats its environment as disposable and its dependency list as the source of truth.
Schedule the next change by library support, not by Python’s own calendar. SPEC 0, the policy that replaced NumPy’s NEP 29, recommends 3 years of support per Python release, while the Python Developer’s Guide schedules 5.
Libraries that adopt it can therefore drop a release 2 years before end-of-life.
When the change comes, check library support for the target version first, then build the new environment beside the old one. Delete the old one only after a clean run.
Checking first avoids a rebuild that cannot install, and the old environment remains the only rollback until the new one runs cleanly. The price is a second interpreter entry and a second folder on disk for a few days.
- Build or Buy an AI Chatbot for E-commerce: The Costs Nobody Budgets For - October 24, 2026
- How to Run a React App in VS Code Step by Step - October 23, 2026
- Transactional or marketing email: which messages your app should send itself - October 23, 2026
