ITensors.jl: tensors that carry their own index identity
A Julia library for efficient tensor computations and tensor network calculations. ITensors.jl is supported by the Simons Foundation's Flatiron Institute.
At a glance
- What is it?
- ITensors.jl is a Julia library for tensor network algorithms where the central idea is that an index is an object that knows which other index it belongs to, so contraction code can be written without bookkeeping. The cost of that design shows up in the release history, where MPS and MPO work was split out into a separate package across two breaking versions.
- Who is it for?
- ITensors.jl fits Julia physicists and students who want tensor network code where contraction order is inferred rather than tracked by hand, and who are willing to install ITensorMPS.jl alongside it for anything touching matrix product states.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly Julia, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 23, 2026, and from our analysis. They are not legal advice.
Editorial analysis
An ITensor is a tensor with a layout-independent interface
The definition the project leads with is short and worth quoting in spirit: an ITensor is a tensor whose interface is independent of its memory layout. Behind that sits the idea that makes the library different from a thin wrapper around an array library. ITensor indices are objects that carry extra information and that recognise each other, comparing equal to one another. That recognition is what lets contraction code be written without the manual index bookkeeping that usually dominates tensor network code, and it is the reason the library exists rather than a generic tensor backend. The audience is the Julia user working on matrix product states, projected entangled pair states or tensor decompositions, and the project topics list reflects that: dmrg, matrix-product-states, peps, tensor-decomposition, tensor-networks and tensor-train sit alongside the general tensors entry.
Three directories that split the library apart
The repository layout mirrors the package structure rather than a single src directory. At the top level sit src, ext, test, docs, examples, NDTensors, Project.toml, CITATION.cff, CODE_OF_CONDUCT.md, Checklists.txt and a .pre-commit-config.yaml. NDTensors is a directory of its own inside the repository, and the release list shows it versioned separately, with NDTensors-v0.4.32 published on the same day as ITensors v0.9.32. That split matters because NDTensors.jl is where the memory layout and the tensor backends live, and the project has been turning experimental internals into standalone packages rather than submodules. The examples directory is organised by algorithm, with basic_ops, ctmrg, trg and an examples/src directory. The extension mechanism in ext is what lets optional packages hook into the type.
MPS and MPO left the package, and code has to follow
The single most consequential change in the project's history is that the matrix product state functionality is no longer part of ITensors.jl. The README points readers who want to run finite MPS or MPO calculations, including DMRG, to the separate ITensorMPS.jl library, which it describes as holding composable and extensible algorithms for optimizing and transforming tensor networks, covering matrix product states and matrix product operators. The move happened in stages. The v0.7 release in October 2024 relocated all MPS and MPO functionality, together with everything from ITensorTDVP.jl, into ITensorMPS.jl, and was called a major breaking change. If you want MPS, MPO, dmrg, siteinds, OpSum or op, you now have to install and load ITensorMPS.jl, and code that said using ITensorTDVP has to say using ITensorMPS instead, with ITensorTDVP deprecated in favour of it.
ITensors.compile and the example-code compilation trick
One detail in that release note is easy to miss and expensive to debug. If you use ITensors.compile, you must install and load ITensorMPS.jl in order for it to trigger properly, because it relies on running MPS and MPO functionality as example code for Julia to compile. This is the kind of coupling that the package split did not fully remove: the main package still depends on the sibling being present for one of its most performance-oriented features to work. The v0.8 release in February 2025 extended the same pattern. It removed internal submodules that held experimental code for rewriting the internals of NDTensors.jl and ITensors.jl, turning them into separate packages for future development, and it was marked breaking because ITensorMPS.jl was using that experimental code. The v0.8 notes also record a fix for very long load and compile times that appeared when ITensors.jl was loaded alongside packages such as LinearMaps.jl in the v0.7 series.
Contraction order now goes through TensorOperations.jl
The v0.9 release in March 2025 was a minor breaking change with a narrow but annoying effect. The optimal_contraction_sequence function now passes to the optimaltree function from TensorOperations.jl, and the TensorOperations package therefore needs to be loaded for optimal_contraction_sequence to be used, or for the flag ITensors.enable_contraction_sequence_optimization() to be switched on. In other words, a performance feature that used to work inside the package now depends on an explicit extra dependency being present in the session. This is a reasonable refactor, since the contraction ordering problem is a well-studied one and reusing an existing implementation beats maintaining a second one, but it moves a failure from compile time to load time and it is the sort of change that only surfaces in production when a user has not added the dependency. There is also the matter of the deleted backend: the v0.6 release removed the experimental combine-contract contraction backend, previously enabled by ITensors.enable_combine_contract(), which had performed contractions by combining indices first and then contracting as matrix multiplications and could lead to speedups for certain contractions involving higher-order QN-conserving tensors.
Getting the library and the documentation you will need
The README does not give an installation command, so there is nothing to copy here, and the project points elsewhere instead. Source code is on GitHub at ITensor/ITensors.jl, the package is published on JuliaHub as ITensors with a version badge pointing at the JuliaHub package page, and additional documentation lives on the project website itensor.org, with the stable and dev documentation builds hosted at docs.itensor.org. The citation information is in the same header, pointing to a SciPost code deposit with the identifier 10.21468 and the arXiv paper 2007.14822, and CITATION.cff sits at the root of the repository. For the matrix product state side of the work, the documentation moved: the v0.8.3 release in March 2025 relocated all MPS and MPO documentation to the ITensorMPS.jl documentation. The package is supported by the Flatiron Institute, a division of the Simons Foundation, through its Flatiron Center for Computational Quantum Physics, and it is Apache-2.0 licensed with a style guide maintained separately in ITensorFormatter.jl.
Two years of release notes are the real documentation
If you are evaluating this library, the News section of the README is the part to read, because it doubles as a migration guide. It records that ITensors.jl v0.8 had installation issues in older versions of Julia v1.10 and v1.11, with a fix in NDTensors.jl v0.4.4, and it tells you to update your packages if you hit that error on those older Julia versions. It also records that v0.8 was not expected to be breaking for the average user of documented features, unlike v0.7. The package is moving quickly: the most recent releases are v0.9.32 and NDTensors-v0.4.32 on 2026-09-27, and v0.9.31 on 2026-09-11, with the last push to the repository on 2026-10-19. That cadence is a feature for a research library, and it is also the reason an upgrade touches your import lines. Two broad cases make ITensors.jl the wrong choice. The first is code that needs MPS, MPO and DMRG to remain in a single package, because that is exactly what the project stopped offering in v0.7. The second is a setting where every additional dependency is a cost, since the contraction path now needs TensorOperations.jl loaded and the compile feature needs ITensorMPS.jl loaded, and a project that has to support older Julia versions has to check the installation notes before it plans a version bump.
Editorial conclusion
ITensors.jl fits Julia physicists and students who want tensor network code where contraction order is inferred rather than tracked by hand, and who are willing to install ITensorMPS.jl alongside it for anything touching matrix product states. It does not fit a team that needs MPS, MPO and DMRG to stay in one package, or one that wants a stable API without reading release notes before every upgrade, because v0.7 and v0.8 both broke the interface and v0.9 changed the contraction path. Before you commit, read the v0.7 and v0.8 entries in the README to see which imports you will have to change, and confirm the Julia version you target is newer than the v1.10 and v1.11 versions that had installation problems.
Frequently asked questions
What is an ITensor in ITensors.jl?
An ITensor is a tensor whose interface is independent of its memory layout. Its indices are objects that carry extra information and that recognise each other, comparing equal to one another, which is what removes much of the manual bookkeeping from contraction code.
Where do I get MPS and DMRG functionality in ITensors.jl?
In the separate ITensorMPS.jl package. Since v0.7 all MPS and MPO functionality, along with everything from ITensorTDVP.jl, has moved there, so code using MPS, MPO, dmrg, siteinds, OpSum or op must install and load ITensorMPS.jl.
Why does optimal_contraction_sequence need another package loaded?
Since the v0.9 release, optimal_contraction_sequence passes to the optimaltree function from TensorOperations.jl, so the TensorOperations package has to be loaded for it to be used, or for ITensors.enable_contraction_sequence_optimization() to be switched on.
Is ITensors.jl still being updated?
Yes. The recent releases include v0.9.32 and NDTensors-v0.4.32 on 2026-09-27 and v0.9.31 on 2026-09-11, and the last push to the repository was on 2026-10-19. The repository is not archived.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/itensor-itensors-jl)Was this useful?