# tensorboardX: writing TensorBoard event files from PyTorch without TensorFlow

> tensorboardX is a small Python package that writes TensorBoard event files from PyTorch, NumPy, Chainer or MXNet code. It is a logging front end, not a training framework, and the README does not document rollback or migration paths.

**lanpa/tensorboardX** — tensorboard for pytorch (and chainer, mxnet, numpy, ...)

- Repository: https://github.com/lanpa/tensorboardX
- Website: https://tensorboardx.readthedocs.io/en/latest/tensorboard.html
- Stars: 7,998 · Forks: 851
- Language: Python
- License: MIT
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/lanpa-tensorboardx

## The gap tensorboardX fills for PyTorch users

TensorBoard is a browser UI that reads event files from a log directory. Historically the code that wrote those files shipped inside TensorFlow, so a PyTorch user who wanted the UI had to install TensorFlow or give up the visualization. tensorboardX is the part that writes the files. The README describes it as "Write TensorBoard events with simple function call", and the package description in pyproject.toml is blunter: "TensorBoardX lets you watch Tensors Flow without Tensorflow". The audience is anyone running a training loop in PyTorch, Chainer, MXNet or plain NumPy who wants scalars, images, histograms and embeddings rendered in a browser tab. The package itself carries only three runtime dependencies (numpy, packaging, protobuf>=3.20), so it does not drag a deep learning framework along with it. If you already have torch installed, tensorboardX adds almost nothing to your environment.

## How SummaryWriter turns tensors into event files

The entry point is a SummaryWriter object. You construct it, call add_scalar, add_image, add_histogram and similar methods, and each call serializes the value into a protobuf record appended to an event file inside a log directory. The default directory is runs, which is why the README's demo flow ends with tensorboard --logdir runs. The writer buffers and flushes asynchronously, so the training loop is not blocked on disk I/O for every call, and writer.close() is what guarantees the remaining records land. Two details matter in practice. First, names containing a slash create a grouping hierarchy in the UI: the README's demo logs data/scalar1 and data/scalar2, which appear under a data group rather than as two top-level entries. Second, add_scalars takes a dictionary and writes several series in one call, which the demo uses for xsinx, xcosx and arctanx. The supported summary list in the README covers scalar, image, figure, histogram, audio, text, graph, onnx_graph, embedding, pr_curve, mesh, hyper-parameters and video. There is also writer.export_scalars_to_json, which dumps scalar data to a JSON file for processing outside TensorBoard. That export path is worth knowing about because it is the only documented way to get numbers out of the event files without reading protobuf yourself.

## Installing tensorboardX and logging a first scalar

The README gives a single install command. It works on Python 3.10 through 3.13, which is the range declared in pyproject.toml and the range the README says the current release is tested against.

```bash
pip install tensorboardX
```

Two optional extras are documented. Installing crc32c is described as speeding things up, and soundfile is required for add_audio() since tensorboardX 2.1, with the README claiming a 200x speedup for that function. Neither is needed for a first run. If you prefer to build from source, the README gives this form:

```bash
pip install 'git+https://github.com/lanpa/tensorboardX'
```

A minimal logging loop looks like the README's demo, trimmed to scalars. The writer takes the log directory, and each add_scalar call takes a tag, a value and a step.

```python
from tensorboardX import SummaryWriter

writer = SummaryWriter('runs/experiment1')
for n_iter in range(100):
    writer.add_scalar('data/loss', 1.0 / (n_iter + 1), n_iter)
writer.close()
```

After that, start the UI against the same directory and open the printed address in a browser. The event file is written on disk before TensorBoard starts, so nothing appears in the browser until the writer has flushed at least one record.

```bash
tensorboard --logdir runs
```

The repository ships runnable versions of this under examples/. The README points at examples/demo.py, which exercises scalars, images, audio, text, histograms, a PR curve and an embedding in one script, and the examples directory also contains demo_comet.py, demo_onnx.py, demo_hparams.py and demo_graph.py for the less common summary types.

## Where tensorboardX stops being the right tool

tensorboardX writes files. It does not run training, schedule jobs, store artifacts or compare runs for you. If you need experiment tracking with a server, a database and a comparison view, this package is one layer too low in the stack, and the README's own Comet integration note points at that gap: it describes Comet as adding dataset management and experiment diffing on top of TensorBoard, and says the integration requires an additional line of code. A second boundary is the UI. The README does not document any way to view the summaries without installing the tensorboard package and running its server, so tensorboardX alone gives you binary event files and nothing to look at. A third is version coupling on the reading side. The README states the current release is tested with PyTorch 2.6, torchvision 0.21.0 and tensorboard 2.19.0, which tells you the project tracks specific reader versions rather than claiming compatibility with every TensorBoard build. Finally, the audio path has a hard dependency: without soundfile installed, add_audio() is not usable, and the README does not describe a fallback.

## tensorboardX versus torch.utils.tensorboard

The realistic alternative is torch.utils.tensorboard.SummaryWriter, which ships inside PyTorch. Both write TensorBoard event files, and both expose similarly named add_* methods, so the difference is not in the output format. The difference is in what you install and what you inherit. torch.utils.tensorboard requires the tensorboard package as a dependency and lives inside the PyTorch release cycle, so its behavior moves when you upgrade torch. tensorboardX is a separate package with its own release cadence and a dependency list of numpy, packaging and protobuf, which means it can be installed in an environment where torch is not present at all. That matters for the non-PyTorch users the README names: Chainer, MXNet and NumPy. The examples directory contains a chainer subdirectory, and demo_nvidia_smi.py and demo_openvino.py cover cases where the logged values do not come from a PyTorch tensor. If your only consumer is a PyTorch training loop, torch.utils.tensorboard is the shorter path and there is no reason to add a second writer. If you log from NumPy arrays, from an ONNX graph, or from a framework that is not PyTorch, tensorboardX is the one that does not assume a torch install.

## Maintenance, licence and the cost of upgrading

The repository is not archived, and the last push was on 2026-07-14. The most recent release listed is v2.6.5 on 2026-04-04, following v2.6.4 on 2025-09-05, and before that a jump back to 2.5 on 2022-06-05. That gap between 2.5 and 2.6.4 is the useful signal for upgrade planning: this project has had long quiet stretches punctuated by releases, so pinning a version in your requirements file is more sensible than tracking master. The licence is MIT, declared both in the repository's LICENSE file and in the license field of pyproject.toml. MIT is permissive, so embedding the package in a commercial training pipeline is the kind of use the licence text permits, but the usual caveat applies: the package ships no warranty, and the README does not document any support commitment. The upgrade surface is small because the public API is a writer object and a set of add_* methods. The two documented breaking-ish changes are dependency additions rather than signature changes: crc32c became an optional speedup, and soundfile became required for add_audio() starting in 2.1. If you use add_audio(), that second one is the line to check before bumping. Development tooling is documented in the Makefile, which offers init, compile, test, coverage, lint, format and docs targets, with init creating a Python 3.13 virtual environment through uv.

## Choosing between tensorboardX and staying with torch

The decision is mostly about which framework your logging calls sit next to. A team training in PyTorch with no other framework in the loop gets nothing from tensorboardX that torch.utils.tensorboard does not already provide, and adds a dependency that must be upgraded separately. A team logging from NumPy, from Chainer, from MXNet, or from a mixed pipeline where some values are arrays and some are tensors is exactly who the package is built for, and the examples directory reflects that with chainer, onnx, openvino and nvidia-smi demos. The second consideration is how much you rely on the less common summary types. If your dashboards need mesh, hyper-parameters, pr_curve or onnx_graph, check the README's supported list against what you need before adopting, because the list is the project's own statement of scope and it is not exhaustive of everything TensorBoard can display. The third is version pinning. Given the release history, pin the version you validate against, and re-run the examples/demo.py script after any bump to confirm the writer still produces files your TensorBoard build can open.

## Conclusion

Adopt tensorboardX when your training loop is PyTorch or NumPy and you want TensorBoard's UI without pulling in TensorFlow. Skip it if your stack already logs through torch.utils.tensorboard, since the two write the same event format and running both adds nothing. Before committing, check that the summary types you need appear in the README's supported list, and confirm your Python version is 3.10 or newer, which pyproject.toml sets as requires-python.

## FAQ

### How do I install tensorboardX?

Run pip install tensorboardX. The README also gives a from-source form, pip install 'git+https://github.com/lanpa/tensorboardX', and notes two optional extras: crc32c for speed and soundfile, which is required for add_audio() since version 2.1.

### How do I use tensorboardX?

Import SummaryWriter from tensorboardX, construct it with a log directory, and call add_scalar, add_image, add_histogram and the other add_* methods inside your training loop. Call writer.close() at the end, then run tensorboard --logdir on the same directory to view the results.

### Can TensorBoard be used with PyTorch?

Yes. tensorboardX writes TensorBoard event files from PyTorch code, and the README's demo imports both torch and tensorboardX to log scalars, images, audio and histograms. The tensorboard package is still what serves the UI; tensorboardX only produces the files it reads.

### Is TensorBoard still used?

No usage figures are published with the project. What the repository does show is a release on 2026-04-04 and a push on 2026-07-14, and the README still documents an active integration with TensorBoard's event format.

### How do I pip install TensorBoard?

The README documents pip install tensorboardX for this package. The tensorboard package itself is what serves the UI, and the README's demo flow runs tensorboard --logdir runs after the writer has produced event files.

## Sources

- [lanpa/tensorboardX on GitHub](https://github.com/lanpa/tensorboardX)
- [License: MIT](https://github.com/lanpa/tensorboardX/blob/master/LICENSE)
- [Project website](https://tensorboardx.readthedocs.io/en/latest/tensorboard.html)
- [README](https://github.com/lanpa/tensorboardX/blob/master/README.md)
- [Releases](https://github.com/lanpa/tensorboardX/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/lanpa-tensorboardx