Quart: an async Python web framework that keeps the Flask API

What Quart solves, and who it is written for

Flask's request handling is synchronous. A view function that awaits a database call cannot simply be declared async, because the framework around it is not built for that. Quart is Pallets' answer: an asyncio reimplementation of Flask, described in pyproject.toml as "A Python ASGI web framework with the same API as Flask". The README states the intent plainly: if you understand Flask, you understand Quart.

The audience is therefore narrow and specific. It is a team that already has Flask code, or Flask habits, and now wants WebSockets, streaming request and response data, or an async HTTP stack without learning a new routing model, a new template engine, or a new extension ecosystem. The README lists what you can build with it: rendered HTML templates, RESTful JSON APIs, WebSockets, and streamed request and response data. That is a general purpose web framework, not a specialist tool.

The cost of that positioning is that Quart inherits Flask's shape. Routing decorators, the application object, blueprints, Jinja templates, and the extension model all come from the parent project. If you dislike how Flask structures an application, Quart will not talk you out of it.

The asyncio reimplementation, and what that means for data flow

Quart is an ASGI framework. The dependency list in pyproject.toml makes the stack visible: hypercorn for serving, werkzeug for the HTTP primitives, jinja2 for templates, itsdangerous for signing, blinker for signals, click for the command line, and flask itself, which Quart depends on at version 3.0 or later. That last dependency is the interesting one. Quart is not a fork frozen at some old Flask revision; it is built on top of a current Flask and reimplements the request and response path around asyncio.

In practice, a view function is declared async and awaits whatever it calls. The README example shows a route returning a rendered template with await, a route returning a plain dict that becomes a JSON response, and a WebSocket route that loops, awaiting websocket.send and websocket.send_json. The same async keyword applies to reading request data and to producing the response.

Because the interface is ASGI, the server is not baked into the framework. Hypercorn is the default in the dependency list and the documentation covers deployment separately, but the README does not describe an alternative server in the quickstart. Anyone planning a production rollout should read the deployment tutorial rather than infer a topology from the quickstart.

Installing Quart and a first runnable application

The README gives the install step as a single pip command. It assumes an installer such as pip and a Python version that satisfies the requires-python field in pyproject.toml, which is 3.13 or newer.

pip install quart

After that, the README's quickstart saves the following as app.py. It is worth reading closely, because it demonstrates three different response paths in one small file: a rendered template, a JSON body returned as a dict, and a WebSocket endpoint.

from quart import Quart, render_template, websocket

app = Quart(__name__)

@app.route("/")
async def hello():
    return await render_template("index.html")

@app.route("/api")
async def json():
    return {"hello": "world"}

@app.websocket("/ws")
async def ws():
    while True:
        await websocket.send("hello")
        await websocket.send_json({"hello": "world"})

The template route expects an index.html in the usual Jinja template location, so that file has to exist before the first route will render. The JSON route returns a dictionary directly, with no serialisation call, which is the Flask convention carried over. The WebSocket route loops forever, sending a text frame and then a JSON frame; it is an illustration, not a pattern to copy into production, since nothing in the README example terminates the loop or handles a client disconnect.

The development server is started with the quart command, which pyproject.toml registers as the entry point quart.cli:main. The README shows the output the reader should expect.

quart run
 * Running on http://127.0.0.1:5000 (CTRL + C to quit)

That is the whole first-use path: install, write app.py, run. There is an optional dependency group for dotenv, which installs python-dotenv, and the repository also carries examples/api, examples/blog, examples/chat and examples/video if you want something larger than the quickstart.

Migrating a Flask application, and where find and replace stops

The README makes a claim that deserves scrutiny: migration should be possible by replacing flask with quart and adding async and await keywords. The project also publishes a dedicated migration guide under its documentation.

That claim is about the API surface, and it is credible given that Quart depends on Flask 3.0 or later and describes itself as having the same API. It is not a claim about your application as a whole. The README notes that a number of Flask extensions work with Quart, which is a careful phrasing: some do, and the sentence does not say all of them. Extensions that reach into request handling, background work, or the synchronous view contract are the ones most likely to need attention. The README does not enumerate which extensions are compatible, so the only reliable check is your own test suite against the migrated code.

There is also a version constraint that a find and replace will not fix. Quart requires Python 3.13 or newer. A Flask application running happily on an older interpreter cannot move to Quart without moving its runtime first, and that is often the larger piece of work.

What Quart is not suited for

The most concrete limitation is the maturity label. pyproject.toml classifies the project as "Development Status :: 4 - Beta". That is the project's own description of itself, not an outside assessment, and it sits oddly beside a dependency on Flask 3.0 and a release history that includes 0.22.0, 0.23.0 and 0.23.1. A team with a policy of depending only on frameworks that label themselves stable has its answer here without reading further.

The second limitation is the interpreter floor. Python 3.13 or newer excludes a large amount of deployed infrastructure, and there is no documented fallback for older versions.

The third is the WebSocket example itself. The README's ws function loops without a break condition and without handling disconnection. Anyone building a real-time feature will need to design their own lifecycle, and the README offers no guidance on that. The chat and video examples in the repository are the place to look for something more complete.

Finally, Quart is the wrong tool if async is not actually your problem. If your application is request-and-response over a synchronous database driver, the async keyword buys you nothing and you carry the compatibility risk of a younger framework for no benefit. Flask itself would be the simpler choice.

Quart against Flask, and against other async frameworks

The honest comparison is with Flask, because Quart is Flask with asyncio underneath. The difference in approach is the concurrency model, not the programming model. In Flask, a view function runs to completion on a worker; concurrency comes from having multiple workers or threads. In Quart, a view function is a coroutine that can await, so a single worker can interleave work while waiting on I/O. The README's framing is that this is a reimplementation rather than an extension, which is why the two cannot simply be mixed.

The practical consequence is that Quart is a migration target, not a parallel option. You do not add Quart to a Flask application the way you add an extension. You replace the framework and then deal with whatever your extensions and your deployment did.

Against other async Python frameworks, the difference is the API and the ecosystem rather than the concurrency model. Quart's bet is that Flask familiarity and Flask extension compatibility are worth more than a fresh design. That bet is legible in the dependency list, where flask>=3.0 appears as a runtime requirement. A framework that depends on Flask to provide its own API is making a deliberate choice about where its value lies.

Maintenance, licence and the cost of upgrading

The repository is not archived, and the last push was on 2026-09-12. Releases 0.22.0, 0.23.0 and 0.23.1 all carry that same date, which suggests a batch of releases rather than a long, evenly paced cadence. The changelog lives at the Changes URL in pyproject.toml, and CHANGES.md is present at the top level, so the upgrade path is documented rather than left to release notes on a hosting page.

The version numbers matter for planning. The project is in the 0.x range, where minor version bumps are the conventional place for breaking changes. A team adopting Quart should expect to read CHANGES.md before each minor upgrade, and should treat the Beta classifier as consistent with that expectation rather than as an oversight.

The licence is MIT, declared in pyproject.toml as license = "MIT" with license-files = ["LICENSE.txt"]. MIT is permissive and imposes no copyleft obligation on your application. That is a statement about the licence text, not legal advice; the LICENSE.txt file in the repository is the authoritative document, and it is the file to read if your organisation has specific requirements.

Editorial conclusion

Adopt Quart if your team already knows Flask and you need WebSockets, streaming request and response data, or an async stack in the same programming model, and you can run Python 3.13 or newer. Do not adopt it if you are on an older interpreter, if you want a framework whose API is not tied to Flask's, or if you need a stability label stronger than the Beta classifier in pyproject.toml. Before committing, read the Flask migration guide, check that each Flask extension you depend on appears in your own test run, and read the deployment tutorial, since the README only points at it rather than describing a production setup.

Frequently asked questions

Official sources

1. License: MIT
2. pallets/quart on GitHub
3. Project website
4. README
5. Releases