Flask vs Django

Flask and Django are both popular Python web frameworks.

The right choice depends on your project constraints and your team’s preference.

The core difference

• Flask gives you a minimal core and lets you add what you need.
• Django includes a full set of features and conventions out of the box.

Think of it like this:

• Flask: “here are the building blocks, build your architecture.”
• Django: “here’s the architecture, follow the pattern.”

Quick comparison table

Topic	Flask	Django
Style	Minimal + extensions	Batteries included
Learning goal	Great for understanding internals	Great for building quickly
ORM	Optional (Flask-SQLAlchemy)	Built-in ORM
Admin panel	Optional (Flask-Admin)	Built-in admin
Project structure	You decide	Strong conventions
APIs	Great (plain Flask, or Flask-RESTful style)	Excellent (Django REST Framework)

When Flask is a great choice

• You’re learning web backends and want to understand each layer
• You want a small service/API or a microservice
• You want full control over libraries (ORM, auth, settings)
• You’re building a custom architecture or integrating into an existing ecosystem

When Django is a great choice

• You want a full website quickly (auth, admin, ORM, forms)
• Your team prefers conventions and a standard layout
• You’re building a content-heavy web app (CMS-like)
• You expect many common features and want less assembly work

A common real-world approach

• Flask for APIs/internal tools/microservices
• Django for “product apps” that want admin + full-stack features quickly

This tutorial track uses Flask because it teaches you the fundamentals clearly, and you can still build production apps with it.

Measured, not asserted

The usual framing is “Flask is lightweight, Django is heavy”. Measured in clean virtual environments on CPython 3.14.4, that is only partly true:

	Flask 3.1.3	Django 6.1
packages installed	9	5
site-packages on disk	19 MB	56 MB
files in a minimal app	1	6
lines in a minimal app	6	203

Django installs fewer distributions, because it is one large package that includes its ORM, admin, auth, forms and migrations. Flask installs more distributions that add up to less code, because it delegates to Werkzeug and Jinja2 and simply has no ORM or auth to ship.

So the honest summary is not “small versus large” but assembled versus included.

diagram Diagram mermaid

  flowchart TD
  subgraph FL["Flask: you choose each piece"]
    F1["routing + WSGI: Werkzeug"]
    F2["templates: Jinja2"]
    F3["ORM: your choice, or none"]
    F4["auth: your choice"]
    F5["admin: build it or skip it"]
  end
  subgraph DJ["Django: decided for you"]
    D1["routing, templates, ORM,
auth, admin, migrations,
forms - one coherent set"]
  end

The minimal app, side by side

flask: app.py — the entire application

from flask import Flask
app = Flask(__name__)
 
@app.route("/")
def index():
    return "Hello"

django-admin startproject demo produces 6 Python files and 203 lines before you have written a single view: manage.py, settings.py, urls.py, wsgi.py, asgi.py and __init__.py.

That difference is the whole trade-off. Flask’s six lines assume nothing, so everything beyond them is a decision you make and maintain. Django’s 203 lines have already decided how settings, URLs, deployment entry points and the ORM fit together.

Choosing between them

choose Flask when	choose Django when
the service is an API or a few endpoints	you need users, an admin, and a database on day one
you want a specific ORM, or none	the built-in ORM and migrations suit you
you are adding HTTP to an existing library	a team benefits from one prescribed layout
the app must stay small and explicit	the app will grow and need conventions

Neither choice is permanent, but they are not symmetric

Growing a Flask app into something Django-shaped means selecting and wiring an ORM, auth, migrations and an admin yourself — real work, but incremental. Shrinking Django is harder, because its parts assume each other. Pick based on the features you know you need within a few months, not on which framework is fashionable.

See it move

sketch Assembled versus included p5.js Pause Restart

Flask ships the HTTP layer and leaves the rest to you. Django includes a decided set of components that assume each other.

Check yourself

pch.quizTag pch.quizDefaultTitle

1. Measured in clean venvs: Flask 9 packages / 19 MB, Django 5 packages / 56 MB. What is the accurate summary?

   A Flask is lighter by every measure B Django is lighter by every measure C Flask is smaller on disk but installs more distributions, because it is assembled from independent libraries while Django is one included set D the two are equivalent in size
   pch.quizShowAnswer

   C — Flask is smaller on disk but installs more distributions, because it is assembled from independent libraries while Django is one included set — Django is a single large distribution carrying its ORM, admin and auth. Flask delegates to Werkzeug and Jinja2, so it has more packages and far less code. The real axis is assembled versus included.

2. A minimal Flask app is 6 lines in 1 file; django-admin startproject produces 203 lines across 6 files. What does the difference represent?

   A Django is less efficient at generating code B Django has already decided how settings, URLs and deployment entry points fit together, while Flask leaves each to you C the Flask app is incomplete D Django requires more code for the same features
   pch.quizShowAnswer

   B — Django has already decided how settings, URLs and deployment entry points fit together, while Flask leaves each to you — Those 203 lines are structure, not logic: settings, urls, wsgi and asgi. Flask assumes none of it, which is freedom and also work you own.

3. Why is moving from Flask to Django harder than the reverse in practice?

   A Django cannot import Flask code B Django's components assume each other, so adopting or removing parts piecemeal is difficult, whereas a Flask app grows by adding chosen pieces C Flask apps cannot be deployed the same way D Django does not support APIs
   pch.quizShowAnswer

   B — Django's components assume each other, so adopting or removing parts piecemeal is difficult, whereas a Flask app grows by adding chosen pieces — Django's ORM, auth and admin are designed together. Flask grows incrementally because each piece was already an independent choice. Choose on the features you need within a few months.