Introduction

Checking the Django version is easy, but checking the right Django version is where people slip. The answer depends on whether you mean the version installed in your shell, the version inside a virtual environment, or the version your deployed application is actually running.

The Most Reliable Command

The best default is to ask the Python interpreter directly:

python -m django --version

If your machine uses python3 as the correct command, use:

python3 -m django --version

This is more reliable than django-admin version because it tells you which Django package the currently selected interpreter can import. That matters on machines with several Python installations.

If you are inside a project and want to confirm which interpreter you are using first, check:

which python
python -m django --version

On Windows Command Prompt, use:

where python
python -m django --version

Check the Version From Python Code

When you are already in a REPL, a debug session, or an application startup hook, inspect the version from Python itself.

1import django
2
3print(django.get_version())
4print(django.VERSION)

django.get_version() returns a readable string such as "5.1.3". django.VERSION returns a tuple, which is better for conditional logic:

1import django
2
3if django.VERSION >= (5, 0):
4    print("Use the modern code path")
5else:
6    print("Use the compatibility path")

Use the string for display and the tuple for comparisons.

Check Through manage.py

If you want to verify the version in the exact project context, run the check through manage.py. That ensures you are using the interpreter and environment associated with that project.

python manage.py shell -c "import django; print(django.get_version())"

This is especially helpful in monorepos or CI jobs where the shell may not obviously match the project environment.

You can also open the Django shell interactively:

python manage.py shell

Then run:

import django
django.get_version()

Verify the Environment First

The command is only useful if you run it in the correct environment. Common patterns include:

Virtual environment:

source .venv/bin/activate
python -m django --version

Pipenv:

pipenv run python -m django --version

Poetry:

poetry run python -m django --version

Docker:

docker compose exec web python -m django --version

This distinction matters because the version on your laptop's global Python may have nothing to do with the version inside the app container or deployment environment.

Inspect Package Metadata

If you also want the install location and package metadata, pip show is useful:

python -m pip show Django

Typical output includes:

• package name,
• version,
• installation path,
• and dependencies.

This can help when debugging issues caused by unexpected site-packages locations or mixed interpreters.

Add a Runtime Check in Application Code

Sometimes you want the running server to report the version at startup or in logs. A small snippet can help:

1import django
2import logging
3
4logger = logging.getLogger(__name__)
5logger.info("Running with Django %s", django.get_version())

That is more trustworthy than reading a requirements file because it reflects the environment actually executing the code.

Why Requirements Files Are Not Enough

A requirements.txt, Pipfile.lock, or pyproject.toml entry tells you what the environment should contain. It does not prove what is installed right now.

For example, the lock file might pin Django 5.1, but the virtual environment might still have 4.2 because dependencies were not reinstalled. Runtime inspection catches that mismatch immediately.

Common Pitfalls

The most common mistake is forgetting to activate the virtual environment and then checking the global interpreter by accident. The command succeeds, but it answers the wrong question.

Another mistake is using django-admin version when several Python installations are present. That command depends on the django-admin script found on the PATH, which may not match your project interpreter.

Developers also sometimes trust the dependency file instead of the environment. Configuration files describe intent; import-based checks describe reality.

Finally, if the project runs in Docker or on a remote host, checking the local shell is not enough. Ask the runtime that is actually serving the app.

Summary

• Use python -m django --version as the most dependable general check.
• Run the check inside the same environment the project uses.
• Use django.get_version() or django.VERSION inside Python code when needed.
• 'python -m pip show Django is useful for package metadata and install location.'
• When debugging deployments, check the container or server runtime, not just your local machine.