Netron: inspecting ONNX, TFLite and PyTorch model files without writing code

The problem Netron solves: a model file is not readable by any other tool you have

A .onnx, .tflite or .mlmodel file is a serialized graph. Opening one in a text editor gives you a header and binary noise. Opening it in Python means writing a loader for that specific format, walking the nodes, and printing shapes, which is a different script for every framework. Netron replaces that with a single viewer that takes a file path and renders the graph.

The audience is narrow and specific. It is for the engineer who received a model from another team and needs to know how many inputs it has, what the input tensor is named, and whether the last layer is a Softmax or a logit output. It is for the person debugging an export that produced the right accuracy but the wrong graph. It is also for reading a published model before deciding whether to use it, which is why the README lists sample files with direct open links, such as a squeezenet ONNX file and a yamnet TensorFlow Lite file, each paired with a netron.app URL that loads it in the browser.

One viewer, many formats, and a long list of experimental ones

The README separates its format support into two tiers. Fully supported: ONNX, TensorFlow Lite, PyTorch, torch.export, ExecuTorch, TorchScript, TensorFlow, Core ML, OpenVINO, Keras, Caffe, Darknet, Safetensors and NumPy. Experimental: MLIR, JAX, GGUF, RKNN, ncnn, MNN, PaddlePaddle and scikit-learn.

That word matters. A format listed as experimental means the parser exists but the project does not promise it handles every file you throw at it. GGUF, for instance, covers a wide range of quantization layouts, and the README gives no detail on which ones render correctly. If your model is in an experimental format, treat a successful render as a bonus and a failure as expected, not as a bug report.

The breadth is the point. Most competing viewers are tied to one ecosystem: a TensorBoard graph tab only shows TensorFlow graphs, and a PyTorch-specific tool only shows PyTorch. Netron's value is that the same window opens a Core ML .mlmodel and a Darknet .cfg, which is what you want when you are comparing an original model against its converted form.

Installing Netron and opening your first model

There are four install paths in the README, and which one you pick depends on whether you want a file association or a scriptable viewer.

The browser version needs no install at all. The README points to netron.app, and the sample model links use a query parameter to load a remote file directly. You can also drag a local file onto the page.

On macOS, the README gives a Homebrew cask:

brew install --cask netron

On Windows, the README gives a winget command:

winget install -s winget netron

Linux users download the .deb or .rpm from the releases page; the README does not give an apt or dnf repository, so you install the package file yourself.

The Python route is the one that fits into a workflow. The README states that `pip install netron` is followed by running `netron [FILE]` or `netron.start('[FILE]')`. The second form is the interesting one, because it starts a local server and opens the browser, which means you can call it from inside a training or export script without leaving Python. The pyproject.toml confirms the entry point: the console script is named netron and maps to netron:main.

pip install netron
netron model.onnx

After the first command finishes, the second opens the graph. What you should see is a canvas with the input node on one side, the output node on the other, and the layers in between. Clicking a node shows its attributes and, for tensors, the shape and data type. That is the whole interaction model, and it is enough for the questions most people arrive with.

Where Netron stops being the right tool

Netron reads. It does not write. There is no export, no graph surgery, no node deletion, no shape inference fix, and no conversion between formats. If your export produced a graph with a stray Cast node you want removed, Netron will show you the Cast node and nothing more. The fix happens in your framework.

It also does not run models. There is no inference, no latency measurement, no memory estimate. A viewer that renders a graph tells you the graph is structurally what you expected; it says nothing about whether the model executes correctly on your target hardware.

Large models are the practical failure mode. A graph with thousands of nodes is not something a canvas renders usefully, and the README does not document any collapse, grouping or search feature for navigating one. For a large transformer, the browser tab becomes a map you scroll rather than a diagram you read.

Finally, do not treat a clean render as proof of validity. Netron's parsers are permissive in the sense that rendering a node does not require the whole file to satisfy a spec. A model that opens fine in Netron can still fail in an inference runtime.

Netron compared with framework-native graph views

The obvious alternative is the graph view inside whatever framework you already use, most commonly TensorBoard's graph tab. The difference is in the input. TensorBoard consumes a TensorFlow event log or a traced graph produced by that framework, so it shows you what the framework recorded. Netron consumes the model file itself, so it shows you what was actually serialized to disk.

That distinction decides which one you reach for. When a training run looks wrong, TensorBoard is the better instrument, because it carries the run's scalars and step information alongside the graph. When a file on disk looks wrong, Netron is the better instrument, because it reads the artifact rather than a log about the artifact.

The second difference is format coverage. TensorBoard's graph view is a TensorFlow tool; it is not going to open a Core ML .mlmodel or a Darknet .cfg. If your work crosses ecosystems, which is common when deploying a PyTorch-trained model to a Core ML target, you need a viewer that is not owned by either side of that conversion.

Licence, packaging and what maintenance costs you

Netron is MIT-licensed, stated in both package.json and pyproject.toml. That permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. It does not grant trademark rights to the Netron name. Nothing here is legal advice; if you are bundling the code into a product, read the LICENSE file in the repository, which is the authoritative text.

The packaging is unusual and worth knowing before you try to build it. The desktop application is an Electron app, and the devDependencies list electron 44.3.0, electron-builder 26.16.1, @electron/notarize 3.1.1 and @playwright/test 1.63.0. The npm scripts are thin wrappers: `npm start` runs `node package.js start`, and `npm test` runs `node package.js test`, so the real build logic lives in package.js rather than in the script entries. There is a second build path through Python, `python package.py build start`, which is what produces the pip-installable package.

For most users this is irrelevant, because you install a released binary or the pip package. It matters if you want to patch a parser, in which case you are working against two build systems and a Python package whose pyproject.toml declares version 0.0.0, meaning the version is injected at build time rather than stored in the manifest.

Upgrade cost is low. Releases are frequent and the version numbers move in small increments, with v9.2.1, v9.2.2 and v9.2.3 all appearing in August 2026 and the last push to the repository on 2026-08-28. There is no plugin API to break against, because there are no plugins. The risk of upgrading is that a parser changed and a file that rendered before now renders differently, which is exactly why you keep one known-good model file around to open after each upgrade.

Editorial conclusion

Adopt Netron if you need to inspect a model file you did not produce, or confirm that an export preserved the layers you expected. Skip it if you need to edit, convert or profile a model; it reads graphs and does not change them. Before relying on it for a format, open one real file from your own pipeline and check whether the node names and tensor shapes match your exporter's output, because several supported formats are labelled experimental in the README.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes