WebPlotDigitizer: extracting numbers from plot images, and where the hosted version ends

The problem WebPlotDigitizer solves, and who it is for

Published figures are usually the only place a dataset appears. A paper reports a dose-response curve as a PNG, a report shows a time series as a PDF page, and the underlying table is never released. WebPlotDigitizer, referred to as WPD throughout its own documentation, is built for that situation. The README states the premise directly: a large quantity of useful data is locked away in images of data visualizations.

The intended user is a researcher, engineer or analyst who needs a handful of numeric points, not a data pipeline. The README says WPD has been used by thousands in academia and industry since its creation in 2010. That framing matters for expectations. This is interactive software with a human in the loop, not a headless extraction library you call from a script. If your job is to digitize one chart from a paper so you can replot it against your own measurements, the tool fits. If your job is to digitize ten thousand charts overnight, the repository does not offer that path.

Calibration and point placement: the actual mechanism

The extraction model is axis calibration followed by coordinate mapping, which is the standard approach for this class of tool. You load an image, tell the software where known axis values sit, and it converts pixel positions into data coordinates. The computer-vision assistance sits around that core: helping you place points along a curve rather than clicking each one by hand.

What the repository actually contains is the frontend. The top-level entries include javascript/, styles/, templates/, locale/, desktop/ and tests/, and package.json names the entry point wpd.min.js. The build script is build.sh, invoked as a prebuild step, and the bundle is produced by uglifyjs from a combined.js file. That is a browser application assembled from plain JavaScript modules, not a service with an extraction API you can call server-side.

The README is explicit that the frontend is AGPL-3.0 while Automeris AI Assist and other related cloud based systems are closed source and owned by Automeris LLC. So the assisted extraction path that the README points users toward is not in this repository. Anyone reading the source to understand the automatic extraction behaviour will find the manual tooling and the UI, and will not find the cloud component.

Installing WebPlotDigitizer locally with Docker

The README gives two local build paths. The Docker route is the shorter one. From the repository root, the documented command builds dependencies, builds the app and hosts it:

docker compose up --build

compose.yaml defines a single service named wpd, container_name wpd, with NODE_ENV set to development and the port mapping 8080:8080. The volume mount is ./:/usr/src/app, so the working tree is shared into the container. Once it is up, the README says the app is reachable at http://localhost:8080, and the test suite at http://localhost:8080/tests.

Rebuilding after a source change uses a separate documented command:

docker compose run wpd npm run build

There is also a formatting command, docker compose run wpd npm run format, which the README describes as autoformat code. If you prefer to skip Docker, the README lists the equivalent sequence: npm install, npm run build, npm start, with npm run format and npm run test alongside. The npm start script is http-server -o, so it opens a browser for you.

One detail worth reading before you run the container: the Dockerfile sets ENV NODE_ENV development even though a comment above it says production is the default, and the line that would drop privileges, USER node, is commented out. For local development that is fine. If you intend to expose this container beyond your machine, those two lines are the ones to change first.

A first extraction, and what the documentation does not cover

The README does not walk through an extraction. It sends readers to https://automeris.io/docs/ for documentation and to https://automeris.io to sign up. So there is no step-by-step in the repository itself, and I am not going to invent one: the specific menu labels and button names are not published there.

What the repository does tell you is the shape of the work. You supply an image, you establish the axis mapping, and you place points. The interactive part is unavoidable, because the software has no way to know which pixels in your particular figure are data and which are gridlines, annotations or a legend. Budget your time accordingly: a clean, high-contrast plot with a single curve is quick, while a scanned figure with overlapping series and a broken axis will take considerably longer, mostly in deciding what counts as a data point.

The README also notes that WPD does not have an official roadmap and asks contributors to consult before submitting contributions. That is a reasonable request from a project with a single named maintainer, but it does mean you cannot plan against a published feature timeline.

Where WebPlotDigitizer is the wrong tool

The clearest limitation is the one the README implies by omission. The automatic extraction capability that makes the tool attractive at scale is a closed-source cloud service, not part of this AGPL-3.0 repository. The README says to sign up on automeris.io to use WPD. If your institution blocks external services, if your data cannot leave your network, or if you need the extraction logic to be auditable, the assisted path is unavailable to you and you are left with the manual tooling in this repository.

A second constraint is versioning. The releases listed are v4.5 in 2021, v4.6 in 2022 and v4.7 in 2024, while package.json declares version 5.3.0. The repository's own package version and its tagged releases do not line up, so anyone pinning to a release tag is pinning to something older than what the master branch builds. The last push to the repository was on 2026-07-27, so the code is moving, but the release cadence does not match that pace.

Third, this is a browser application. There is no documented command-line extraction interface and no documented HTTP API for submitting an image and receiving coordinates. Package.json lists pdfjs-dist and tarballjs as runtime dependencies, which tells you PDF input and archive handling are in scope, but nothing in the repository suggests scripted batch operation. If your requirement is reproducible extraction inside a CI job, look elsewhere.

WebPlotDigitizer compared with PlotDigitizer and other alternatives

People searching for a WebPlotDigitizer alternative usually land on PlotDigitizer, and the difference is mostly in where the work happens. WebPlotDigitizer is a browser-based application whose frontend is published under AGPL-3.0, so you can build it locally with the Docker commands above and inspect the JavaScript that runs. PlotDigitizer is a separate product with its own hosting and licensing; nothing published in this repository describes its internals, so the honest comparison stops at that boundary.

The more useful distinction is between hosted and self-built. Using automeris.io gives you the AI Assist path and no build step. Building this repository gives you a local instance, full source access, and the AGPL-3.0 obligations that come with it, but not the cloud-assisted extraction. Those are two different products sharing a name, and choosing between them is really a question about whether your data can leave your machine.

For anyone who only needs a few points and does not care about source access, the hosted route is simpler. For anyone who needs the frontend to run inside a controlled environment, the Docker path in compose.yaml is the entry point, and the tests at http://localhost:8080/tests are how you confirm the build is sound before you rely on it.

Licence, maintenance and upgrade cost

The frontend in this repository is distributed under GNU AGPL v3. The README separates that clearly from the closed-source cloud systems owned by Automeris LLC. The practical consequence of AGPL-3.0 is that if you modify the frontend and make it available to users over a network, the licence's source-disclosure terms apply to your modified version. Whether that matters depends on how you deploy it, and it is worth a conversation with whoever handles licensing at your organisation rather than an assumption either way.

On maintenance, the facts are narrow. The repository is not archived, and the last push was on 2026-07-27. The releases are sparse: v4.5 in 2021, v4.6 in 2022, v4.7 in 2024. The README names a single primary author and maintainer, Ankit Rohatgi, and states there is no official roadmap. That combination means upgrades are infrequent and you should not expect a migration guide for every change.

Upgrade cost is dominated by the build chain rather than the application logic. The Dockerfile pins NODE_VERSION=23.10.0 and installs python3, py3-jinja2 and py3-babel via apk, and build.sh runs as a prebuild step before uglifyjs bundles combined.js into wpd.min.js. Any of those moving parts can break a rebuild, so treat the build as something you verify rather than something you assume.

Editorial conclusion

Adopt WebPlotDigitizer if you need numbers out of published charts and you are willing to check every point manually or pay for the closed-source AI Assist service on automeris.io. Do not adopt it if your workflow requires unattended batch extraction of hundreds of images, or if AGPL-3.0 obligations conflict with how you intend to distribute a modified frontend. Before committing, verify two things: that the calibration and point-placement flow matches the plot types you actually have, and that the current automeris.io terms still give you the access the README describes, since the repository ships no roadmap and no release schedule.

Frequently asked questions

Official sources

1. automeris-io/WebPlotDigitizer on GitHub
2. License: AGPL-3.0
3. Project website
4. README
5. Releases