Moving from PlotJuggler 3 to PlotJuggler 4 is not an in-place upgrade — PJ4 is a rewrite, released as 4.0.0 on 21 September 2026, with its own packages, its own layout schema and its own plugin channel. The good news is that nothing forces you to burn the PJ3 bridge: the two lines install side by side, your PJ3 skills transfer almost intact, and the migration can be done calmly, one workflow at a time. This guide separates what carries over from what changes. The context lives on the PlotJuggler 4 hub; both versions are on the Download page.
What carries over
- The core workflow. Drag signals into time-series and XY plots, load several recordings, align timelines, overlay signals — PJ4 works the way PJ3 taught you to work.
- Your everyday data. CSV and PX4 ULog files, the PJ3 staples, are first-class PJ4 formats too, joined by MCAP, Parquet, LeRobot, MP4, PCD and PLY.
- Live-streaming habits. MQTT, ZeroMQ, UDP and WebSocket all exist on both lines; PJ4 adds ROS 2 streaming and WebRTC to the list.
- Transforms, including Lua. Filters, derivatives, integrals and FFT are in PJ4, and Lua custom transforms remain supported — PJ4 adds Python as an alternative rather than replacing Lua (see Python scripting).
- The concepts of layouts and offsets. You still save layouts and use per-dataset time offsets to align recordings — what changed is the layout file schema, covered next.
What changes: layout schema v4
PJ4 layouts use schema v4, which stores the viewport and the per-dataset time offsets along with the rest of the layout. Because the schema changed in a rewrite, the cautious approach is the right one: check your layouts after upgrading. Open each important PJ3 layout in PJ4, confirm that the curves, viewports and offsets look the way you saved them, and re-save the layout from PJ4 once you are satisfied. Do not assume a silent, perfect conversion of every saved view, and do not delete your PJ3 installation or its layouts until the PJ4 copies are verified — treat the first pass as an inspection, not a formality. Equally, do not expect PJ4-saved layouts to be meaningful to PJ3 afterwards; migration of layouts is a one-way street in practice.
What changes: the plugin ecosystem
PJ3 plugins (data loaders, streamers, message parsers, state publishers, toolboxes) were C++ components you obtained and installed yourself, with a sample-plugins repository as the starting point for authors. PJ4 reorganises this world around distribution: the Extensions Marketplace (File → Marketplace) installs and updates loaders, streamers, parsers and toolboxes from the project’s registry, and a dedicated plugin SDK — the plotjuggler_sdk repository — exists for creating PJ4 plugins. The practical migration step is an inventory: list the PJ3 plugins your workflow actually depends on, then check the Marketplace for their PJ4 counterparts before you commit to switching (our Marketplace guide explains how it works). If a plugin you rely on has no PJ4 counterpart yet, that workflow stays on PJ3 for now — which is a normal outcome of a side-by-side migration, not a failure.
Installing side by side (do this first)
The two generations were named to coexist. On Debian/Ubuntu, the PJ4 apt-repository package is plotjuggler4 — distinct from the PJ3 channels: the PJ3 snap (sudo snap install plotjuggler) and the ROS packages (ros-$ROS_DISTRO-plotjuggler-ros). On Windows, PJ4 installs per-user from its own installer file. Follow the Install guides for your platform and install PJ4 without removing PJ3. Then:
- Open PJ4 and load a recording you know well from PJ3 work; confirm the data reads and plots as expected.
- Load your most important layouts and inspect them (schema v4, above); re-save the ones that check out.
- Recreate or port your essential custom transforms — Lua ones carry the concept directly; this is also the moment to try the Python option.
- Check the Marketplace for PJ4 versions of your PJ3 plugins.
- Run one real analysis task end-to-end in PJ4 before making it your default.
The ROS exception — read this before migrating a ROS workflow
If your PlotJuggler use is the ROS workflow — ROS apt packages, topic subscription and rosbag loading through the ROS plugins — then your migration timeline is not yours to choose: the ROS Index still lists the core package at 3.17.2, the ROS plugin packages are built for the PJ3 application, and the ROS ecosystem remains on the PJ3 line. In that case the correct “migration” is: keep PJ3 as your ROS tool, install PJ4 alongside for file-based and multimodal work if you want it, and revisit when the ROS packages move. Our PJ3 vs PJ4 comparison gives the full reasoning.
What does not migrate
Being explicit about the gaps is part of an honest migration guide. PJ4 4.0.0 has no macOS binary (PJ3’s last macOS builds were 3.16.0) and no aarch64 AppImage (PJ3 still ships one) — if either is your platform, PJ3 remains your version for now; see the macOS guide. There is also no snap or flatpak for PJ4. And while most day-to-day concepts transfer, PJ4 is a .0 of a rewritten platform: budget a little evaluation time rather than switching the morning of a deadline.