itables changes how a DataFrame renders, in two lines

The whole integration is two lines

The package changes how Pandas and Polars DataFrames are rendered in Python notebooks and applications, and the promise is that you can turn it on and off in two lines with no other impact on your data workflow. The activation is a call to `init_notebook_mode`:

import itables

itables.init_notebook_mode()

After that, any DataFrame in the notebook is drawn as an interactive table you can sort, paginate, scroll and filter, instead of the usual truncated text. If you would rather be selective, there is a variant that leaves the default display alone. `itables.init_notebook_mode(all_interactive=False)` turns off the blanket behaviour, and you then call `itables.show` on the individual Series or DataFrame that you want interactive. That distinction is the difference between the library being invisible in your code and the library being something you call, and for a large notebook with a mix of throwaway frames and one table you actually care about, the selective mode is the one you want.

No dependencies, and extras that stay optional

The dependency story is unusual for a package in this space, and it is the change worth knowing about. Since version 2.6.0, itables has no dependencies, and it works out of the box with Pandas or Polars in Jupyter, Dash, Streamlit, Shiny, Panel or Marimo, provided those packages are already installed. The single exception is the Jupyter Widget, which needs `anywidget`. Everything else lives in extras, and the list in the packaging configuration is worth scanning because it maps onto the environments rather than onto features. There are extras for the data libraries themselves, `pandas`, `polars` and `narwhals`, a `style` extra that adds matplotlib for formatting, a `notebook` extra for IPython, a `widget` extra with anywidget and traitlets, and then one extra per application framework, for shiny, dash, streamlit and marimo. There are also extras for the job of checking your own code, `check_type` with typeguard, and `typing` for the older Python versions. The practical consequence is that a notebook user pays nothing and an application user pays for exactly the framework they use.

The notebook matrix is broader than Jupyter

The list of environments where the interactive tables work is longer than the word notebook usually implies. The documented ones are Jupyter Notebook, Jupyter Lab and Jupyter nbconvert, and the nbconvert case is the interesting one, because the tables stay interactive in the HTML export of a notebook rather than being flattened to static output. That is a real difference between the library and the default pandas display, and it means a notebook you publish keeps its sort and filter controls. Beyond that it works in Jupyter Book, in Google Colab and on Kaggle, in Quarto HTML documents, and in RISE presentations. The documentation also calls out VS Code specifically, both in notebooks and in interactive Python sessions,. The site at itables.org carries the examples for each of these, which is the fastest way to check the environment you actually use.

Four application surfaces from one package

The same package is available as a Jupyter Widget, as a Dash component, as a Streamlit component, and it also works in Shiny applications. That list is a good summary of where interactive data tables are wanted in Python applications, and the differences between the surfaces are mostly about how the JavaScript is delivered. The widget route is the one with a dependency, since a Jupyter Widget has to be registered with the kernel through anywidget, and the widget is the surface that lets the user interact with the table and then have that interaction reflected back into the notebook's Python state. The Dash and Streamlit components are the ones for a web application, where the table becomes part of the app's layout. Shiny is supported as well, with an extra for shiny and shinywidgets. The packaging reflects this with one extra per framework, and with an `apps/` directory in the repository where the example applications live.

Narwhals is how it stops caring which DataFrame you have

The interesting technical choice is the Narwhals integration, and it changes what the package can display. With Narwhals installed, itables can display DataFrames from other libraries such as cuDF, Modin or PyArrow, and not only from Pandas and Polars. The mechanism is that Narwhals provides a common interface over the dataframe libraries, so the rendering code has one shape to talk to instead of one per library. The `other_dataframes` extra pulls in narwhals, pyarrow and modin with dask, and a separate `narwhals` extra exists for the interface alone. For a GPU dataframe user this is the difference between a table and no table, and for a user who has migrated between Pandas and Polars it means the notebook code does not have to change. The trade is one more layer between your data and the browser, and the rendering options are limited to what that interface exposes rather than to what each library can do.

Packaging details that hint at the project's shape

The packaging configuration is small and tells you how the project is built. The build backend is hatchling with hatch-jupyter-builder, which is the piece that packages the front end assets into the wheel, so the JavaScript is shipped inside the Python package and installed with it. The version is dynamic, so it comes from the repository rather than from a file that has to be edited. The supported Python versions run from 3.9 to 3.14, and the project is classified as Production/Stable and as typed, with a `Typing :: Typed` classifier. The repository layout shows a `src/` directory, a `tests/` directory, a `docs/` directory, an `apps/` directory for the example applications, a `packages/` directory for the front end sources, a `binder/` directory for the hosted demo environment, a `conda.recipe/` directory, a `pixi.lock` for the Pixi environment manager, a pre-commit configuration and a pylint configuration. The presence of a conda recipe alongside the PyPI package means the tool is installable the same way in either ecosystem, and the documentation gives both commands.

What it does not do, and the state of the project

The scope is narrow on purpose, and the documentation says so, that ITables is just about how tables are displayed. It does not change your data, it does not give you editing, aggregation or charts, and it is not a replacement for a grid component with server side data handling. That narrowness is a virtue for the intended use, since a notebook or a small app gets a real table without adopting a grid library, and the wrapper is around DataTables itself, developed by Allan Jardine and also under the MIT licence, so the table behaviour you know from the web is the behaviour you get. Two practical notes for an adopter. The interactive table lives in the browser, so a very large frame means a very large table, and the documentation does not promise otherwise. And the two-line activation is a global setting in a notebook, so a team that wants reproducibility across a repository may prefer the explicit `itables.show` call over the blanket mode. On the state of the project, the releases are 2.9.1 on 2026-07-22, 2.9.0 on 2026-07-19 and 2.8.2 on 2026-07-18, and the last push to the repository was on 2026-10-16, so the package is actively maintained and the MIT licence is unambiguous.

Editorial conclusion

itables suits a data scientist who is tired of scrolling a truncated DataFrame in a notebook, and it suits anyone building a small application around a DataFrame who wants sorting and filtering without writing a grid, since the JavaScript library underneath is already solved. It is a poor fit if your frames are enormous, since the interactivity is a browser side table and the documentation does not claim otherwise, and it is a poor fit if you need the display to be the same in every environment, because the widget path pulls in anywidget while the other paths do not. Before you adopt it, check three things: which of the four application surfaces you actually need, since the extras differ and the Jupyter widget has its own dependency, that your environment is one of the listed ones, from Jupyter and Colab through Quarto and RISE to VS Code, and the version you pin, with 2.9.1 published on 2026-07-22 and the last push to the repository on 2026-10-16.

Frequently asked questions

Official sources

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