# IJulia.jl: the Julia kernel for Jupyter notebooks > IJulia.jl connects the Julia language to Jupyter's notebook interface. It is a small package with a narrow job, and the README is honest about the two ways to install it. **JuliaLang/IJulia.jl** — Julia kernel for Jupyter - Repository: https://github.com/JuliaLang/IJulia.jl - Website: https://ijulia.org/ - Stars: 2,906 · Forks: 426 - Language: Julia - License: MIT - Published: 2026-09-24 · Updated: 2026-09-24 · Language: en - Canonical page: https://hysenlabs.com/projects/julialang-ijulia-jl ## What problem IJulia.jl solves, and for whom Jupyter speaks a kernel protocol, not a language. To run Julia inside a notebook, something has to register a kernel specification that tells the Jupyter server which executable to launch and how to talk to it. IJulia.jl is that something. The README describes it as "a Julia-language backend combined with the Jupyter interactive environment (also used by IPython)", which is a precise way of saying it does not provide the notebook UI or the server. Those come from Jupyter. IJulia provides the Julia side of the conversation. The audience is narrower than the package's popularity suggests. It fits people who already have Jupyter in their workflow and want Julia available as one more kernel choice, and it fits instructors who want students to see plots, math and code in one document. It does not fit people who want an IDE, a debugger or a test runner. The README points at JupyterLab and at the nteract desktop notebook as supported front ends, and notes that notebooks can be reused from other Julia code through the separate NBInclude.jl package, which is a hint that the notebook is not the only way to consume the file. ## How the kernel specification mechanism actually works The mechanism visible in the README is a kernel specification, which the README links to the Jupyter client documentation. When IJulia is added to a Julia environment, it writes a specification that tells Jupyter how to launch Julia. Jupyter then lists Julia alongside whatever other kernels are installed, and launching a notebook starts a Julia process that the Jupyter server talks to over the kernel protocol. The detail that matters in practice is where that specification is written and which Julia it points at. The README states that IJulia "should generally be installed in Julia's global package environment, unless you install a custom kernel that specifies a particular environment". That sentence is the whole design constraint. A kernel specification records a command. If it records a command tied to a temporary project environment, the kernel will break when that environment changes. Installing globally avoids that, at the cost of one Julia environment shared by every notebook you open. The second path is self-contained. Calling notebook() on a machine without Jupyter prompts to install a minimal Python plus Jupyter distribution through Conda.jl, described in the README as private to Julia and not on your PATH. That is convenient and also the source of the most common confusion, because the Jupyter you launched from a terminal and the Jupyter IJulia installed are different installations with different kernel lists. ## Installing IJulia.jl and opening a first notebook The README gives one install path through the Julia package manager. From the Julia REPL, press the bracket key to enter pkg mode and add the package. The README shows the command without the prompt: ```julia add IJulia ``` If Python and Jupyter are already on the machine, the README states that this also installs a kernel specification telling Jupyter how to launch Julia. After that, the notebook server starts the usual way: ```bash jupyter notebook ``` The Julia kernel should appear in the list of available kernels when you create a new notebook. The alternative path has IJulia manage its own Jupyter. At the julia> prompt: ```julia using IJulia notebook() ``` The README states that the first time notebook() runs it prompts for whether it should install Jupyter, and that pressing enter lets Conda.jl install a minimal Python and Jupyter distribution private to Julia. The browser should open on the notebook interface. The README does not document what happens if you decline the prompt, so if you already have Jupyter and want IJulia to use it, the first path is the one the README describes in detail. ## The global environment requirement is a real constraint The recommendation to install IJulia in Julia's global package environment is not a stylistic preference. It follows from how kernel specifications work. A specification names a launch command, and if that command depends on a project environment that later gets garbage collected or updated, the kernel entry becomes stale. The README acknowledges the escape hatch: a custom kernel that specifies a particular environment. That is the right answer for anyone who needs a notebook pinned to a fixed set of package versions, but the README does not walk through creating one. The documentation link is where that lives. The other limitation is the Conda path. A private Miniconda distribution that is not on your PATH means two Jupyter installations coexist. Notebooks created in one will not appear in the other's file listing unless you point them at the same directory, and kernels registered in one are invisible to the other. Nothing in the README says this is a problem, but it is the predictable consequence of the design, and it is the first thing to check when a Julia kernel seems to have vanished. IJulia is also the wrong tool for anything that needs to run headless and reproducibly. A notebook is a document with execution state attached. If the goal is a scheduled job or a package test, a plain Julia script is the correct container and IJulia adds nothing. ## IJulia.jl compared with running Julia through Jupyter's Python kernel The obvious alternative for a mixed-language notebook is to run Julia from a Python kernel using an interoperability layer, so that a single kernel executes both languages in one process. The difference in approach is where the language boundary sits. With IJulia, Julia is the kernel: the notebook process is Julia, the kernel protocol is implemented by IJulia, and Python code, if you need it, goes through a separate bridge. With a Python kernel and an interop layer, Python is the kernel and Julia is called into from it. That distinction decides which tool fits. If most of the notebook is Julia, IJulia keeps the execution model simple and the error tracebacks in Julia. If most of the notebook is Python with occasional Julia calls, a Python kernel avoids the context switch and keeps the notebook's primary language aligned with its kernel. The README does not compare the two, and it does not need to, but the choice is real and it is made before you write any cells. A second alternative is not using a notebook at all. The README mentions NBInclude.jl, which lets other Julia code reuse IJulia notebooks. That is a legitimate workflow for people who want the notebook as a presentation layer over code that is otherwise executed as ordinary Julia. ## Maintenance, licence and upgrade cost The repository is not archived and the last push was on 2026-06-23. The most recent release listed is v1.34.4 from 2026-02-25, preceded by v1.34.3 on 2026-02-13 and v1.34.2 on 2026-02-08. Those three releases inside a single month suggest a patch-heavy period rather than a feature push, and the version numbers stay in the 1.34 line, so upgrades within that line should be low risk. The package is MIT licensed. That is a permissive licence, and it means the source can be reused and redistributed with the licence text retained. It says nothing about the licence of Jupyter itself or of the Miniconda distribution that the Conda path installs, which are separate projects with their own terms. Anyone redistributing a bundled environment should look at those separately rather than treating the MIT licence on IJulia as covering the whole stack. Upgrade cost is mostly the Julia package manager's problem. Because the README recommends the global environment, an update to IJulia updates the kernel for every notebook on the machine at once. That is convenient and also means a broken release is not isolated to one project. Running a custom kernel with a pinned environment is the way to avoid that, and the README says such kernels exist without explaining how to build one. ## Conclusion Adopt IJulia.jl if you already work in Jupyter and want Julia cells next to Python ones, or if you are teaching Julia and want a notebook interface without building a front end. Skip it if your work is a package or a script that needs reproducible execution, because a notebook is a poor container for that, and skip it if you need a kernel running inside a restricted environment where Conda cannot write to disk. Before committing, verify two things: run notebook() once and confirm where the kernel specification lands, and check whether your Jupyter installation is the one IJulia found or the private Miniconda copy it offers to create. ## FAQ ### How do I install IJulia.jl? From the Julia REPL, press the bracket key to enter pkg mode and run add IJulia. The README states that if Python and Jupyter are already installed, this also installs a kernel specification that tells Jupyter how to launch Julia. ### Does IJulia.jl install Jupyter for me? It can. The README states that the first time you run notebook(), it prompts whether it should install Jupyter, and that pressing enter lets Conda.jl install a minimal Python plus Jupyter distribution private to Julia and not on your PATH. ### Where should IJulia.jl be installed? The README states that IJulia should generally be installed in Julia's global package environment, unless you install a custom kernel that specifies a particular environment. ### Which notebook interfaces work with IJulia.jl? The README states that IJulia works with the classic Jupyter Notebook and with JupyterLab, and that the nteract notebook desktop supports it with its own installation instructions. ## Sources - [JuliaLang/IJulia.jl on GitHub](https://github.com/JuliaLang/IJulia.jl) - [License: MIT](https://github.com/JuliaLang/IJulia.jl/blob/master/LICENSE) - [Project website](https://ijulia.org/) - [README](https://github.com/JuliaLang/IJulia.jl/blob/master/README.md) - [Releases](https://github.com/JuliaLang/IJulia.jl/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/julialang-ijulia-jl