The Python Graph Gallery: a Gatsby site where every chart is a notebook

A gallery of chart recipes, not a plotting library

The Python Graph Gallery is a website, and the GitHub repository holds its source code. The project's own description is a website showcasing hundreds of charts made with Python, and the package.json describes it as a gallery displaying hundreds of charts made with Python with their reproducible code. That last clause is the part that distinguishes it from an inspiration site. Every entry ships the code that draws it.

The charts themselves are not drawn by a shared library. There is no `pgg` package to install. What the project centralizes is a collection of Jupyter notebooks, each one self-contained, plus the machinery to render notebooks on a site, produce square thumbnails, and file each chart into a browseable category. The repository is licensed 0BSD, described in the tree as 0BSD in both the LICENSE file and package.json, which is close to public domain and one of the more permissive licenses a codebase can carry.

The site is at python-graph-gallery.com, with an about page linked from the README. The repository is not archived, its default branch is master, and the last push was on 2026-08-19. It carries 2,254 stars and 437 forks, and 18 open issues.

A naming caution is worth stating at the top. Searches for this project's name also surface material about NetworkX and about graph data structures in general, because a python graph is an ordinary phrase. The project is about drawing charts, not about graph theory libraries.

Why Gatsby and what runs in the browser

The site is built on Gatsby 5 with React 18, and the repository root makes the structure plain: gatsby-config.js, gatsby-node.js and gatsby-ssr.js at the top, plus src/, static/, plugins/ and admin/ directories. Gatsby plugins cover images, the manifest, the sitemap and Google analytics, and there is a deploy script wired to gh-pages, which explains a directory named admin as well.

The more interesting dependency is the set of nteract packages: `@nteract/commutable`, `@nteract/display-area`, `@nteract/presentational-components`, `@nteract/records` and `@nteract/transforms`. Those are the components that render a Jupyter notebook, with its markdown, code cells and outputs, directly in the browser rather than as a static image. That is why a gallery of reproducible Python examples can show both the chart and the code that produced it on one page. The rest of the front end is Bootstrap 5 with react-bootstrap, KaTeX for equations through react-katex, Prism for code highlighting, and d3 plus d3-voronoi alongside lucide-react.

So this is a JavaScript project wearing an HTML label in the repository metadata, with Python appearing on the content side. Anyone expecting to pip install the gallery will not find it. The Python lives in the notebooks and in the development environment used to author them.

The Python side: two dozen pinned libraries

The pyproject.toml at the repository root defines the environment used to write and run the notebooks. It requires Python 3.13 or newer, is named the-python-graph-gallery at version 1.0.1, and pins a wide set of plotting libraries:

[project]
name = "the-python-graph-gallery"
version = "1.0.1"
requires-python = ">=3.13"
dependencies = [
    "matplotlib>=3.10.1",
    "seaborn>=0.13.2",

The full dependency list goes considerably past those two. It includes plotnine for grammar-of-graphics charts, polars and pyarrow for data handling, geopandas and cartopy for maps, pywaffle and squarify for the less common layouts, morethemes for styling, and a set of small helpers the author built for this site: bumplot, dayplot, drawarrow, highlight-text, pyfonts and pypalettes. pandas and requests are there too, and ruff is included as the linter.

Two things stand out. First, the floor of Python 3.13 is high, so the authoring environment will not run on an older interpreter without changes. Second, the presence of six author-made helper packages means many gallery recipes are not plain seaborn. A chart involving dayplot or bumplot is using a library most readers have not installed, which changes how portable the recipe is. The pyproject.toml also sets a line length of 70, a detail that hints at how the notebooks are formatted.

Running the site locally in three commands

The README spells out the development setup. You need Git, Node.js, npm and Gatsby installed, then you fork and clone the repository, create a branch, and install dependencies. The last two steps are the npm scripts:

npm install
npm run develop

`npm run develop` builds and previews the site locally. The README warns that this may take one to two minutes, because a Gatsby build processes every notebook in the collection, and then you visit `http://localhost:8000`. package.json defines the surrounding scripts: `build` runs `gatsby build`, `serve` runs `gatsby serve`, `start` aliases `develop`, and `clean` runs `gatsby clean`. There is a prettier format script covering js, jsx, ts, tsx, json and md files, an eslint config at the root, and a test script that is a placeholder which exits with an error.

What a chart entry actually contains

Adding a post is where the project's documentation is strongest, and the answer is that an entry is a Jupyter notebook with a metadata block. You duplicate an existing `.ipynb` file in `src/notebooks/`, rename it in lowercase with hyphens starting at an unused number above 600, and then open it as a text editor rather than in the Jupyter interface so you can reach the metadata without executing anything. The example filename the README uses is `602-combine-boxplot-and-violintplot-using-seaborn.ipynb`.

The metadata fields are specific. `slug` must match the filename without its extension. `title` becomes the page heading, `description` becomes the intro text under it and allows HTML. `family` must be one of seven values: evolution, ranking, distribution, general, correlation, partOfAWhole or flow. `chartType` has to match an identifier in a specific file, sectionDescriptions.js, which is a real constraint rather than a free-text tag. `keywords` feeds the HTML header and `seoDescription` is plain text for meta tags.

Then there is the screenshot step, which is the least obvious part. You capture the plot, make it square and at least 480 by 480 pixels, and move it into `static/graph/`. An ImageMagick shell script in that folder reformats it:

./script_reformat_img.sh my-img-name.png

The image filename has to match the post filename, with `-1.png`, `-2.png` and so on for multiple images. Finally you register the thumbnail in a section file under `src/pages/`, named after the chart family, so the gallery index picks it up:

<ChartImageContainer
  imgName="602-combine-boxplot-and-violintplot-using-seaborn"
  caption="Combine boxplot and violinplot with seaborn"
  linkTo="/602-combine-boxplot-and-violintplot-using-seaborn"
/>

That manual step is the honest cost of adding an entry. Nothing scans the notebooks directory and generates the gallery index; a human edits a page component. The README closes the loop by pointing at a New Post Checklist wiki page before you push.

Where it stops being useful to a working developer

The site's value is speed of lookup, and it delivers that. But it is worth being clear about the three things it does not do.

It is not a package. Nothing here installs into your environment, so the recipe has to be copied out of a rendered notebook by hand. It is not a style guide, because the charts are deliberately varied, covering families from evolution diagrams to flow charts, and picking one for a report means accepting an author's aesthetic rather than a documented convention. And it is not versioned as content. The repository has no GitHub releases, and each notebook pins nothing on the site side, so a recipe written against seaborn 0.13 will drift as the library moves, even though the pyproject.toml floors give you a reasonable starting environment.

There is also no test suite to speak of: the npm test script prints a placeholder message and fails by design. What quality control exists is social. Improvements to an existing post are made by editing its notebook and opening a pull request with @holtzy tagged for review, and the README states that contributions of any size are welcome, from fixing a typo to adding a blog post.

Editorial conclusion

The Python Graph Gallery earns its place as a lookup table rather than a library. If you need a working seaborn or matplotlib recipe in the next ten minutes, the site is the fastest route, and the notebook is the deliverable rather than a screenshot. If you need chart code in your own build, pull the notebook and its pinned dependencies from pyproject.toml instead, since the site itself is a Gatsby application with React components and nteract notebook rendering that you would be taking on wholesale. To contribute, duplicate a notebook above number 600 in src/notebooks, set slug, title, family and chartType, then run npm run develop and open a pull request tagging @holtzy for review.

Frequently asked questions

Official sources

1. holtzy/The-Python-Graph-Gallery on GitHub
2. Issues
3. License: 0BSD
4. Project website
5. README