MNE-Python: an EEG and MEG analysis toolkit for Python

What MNE-Python replaces in an EEG or MEG workflow

The README describes MNE-Python as an open-source Python package for exploring, visualizing and analyzing human neurophysiological data such as MEG, EEG, sEEG, ECoG and more. The word "more" is doing real work there, but the core audience is clear: labs that record electrophysiology and need to get from a raw file to a cleaned, epoched, source-localized result without stitching together five unrelated tools.

The library covers data input/output, preprocessing, visualization, source estimation, time-frequency analysis, connectivity analysis, machine learning and statistics. That breadth is the point. A researcher who filters a recording, rejects bad channels, runs ICA, epochs around events and then fits a forward model is staying inside one package the whole way, which means one object model and one set of conventions rather than a conversion step between every stage.

It is not aimed at clinicians who want a report out of a proprietary viewer, and it is not aimed at people who have never written a script. The documentation is organized around tutorials and examples, and the repository ships an examples directory split by topic (connectivity, decoding, forward, inverse, io, preprocessing, simulation, stats, time_frequency, visualization) plus a separate tutorials directory. That layout tells you what the maintainers expect: you learn by reading and modifying code, not by clicking.

The Raw, Epochs and Evoked object model

The mechanism that holds MNE-Python together is a chain of container types. Continuous data lands in a Raw object. Once you cut it around stimulus or response markers you have Epochs. Averaging those epochs gives an Evoked object. Each stage keeps the channel metadata, the sampling rate and the montage, so downstream functions do not need to be told again what the sensors are.

Around that spine sit the analysis modules named in the README: preprocessing, time-frequency, connectivity, source estimation, machine learning and statistics. The repository's own examples are organized the same way, with separate directories for inverse and forward modelling, decoding, and stats. Source estimation in particular depends on a forward model and a BEM or similar head model, which is why the examples directory separates forward from inverse rather than treating localization as a single step.

One structural detail worth noticing is the dependency list in the README. The minimum requirements are Python 3.11 or newer, decorator, Jinja2, lazy-loader, Matplotlib, NumPy, packaging, Pooch, SciPy and tqdm. That is a deliberately thin core: heavy optional stacks such as scikit-learn, pyvistaqt and neo appear in the pyproject.toml documentation dependency group, not in the minimum set. The practical consequence is that a bare pip install gives you the analysis and plotting machinery but not every visualization backend or every optional file format reader.

How to install MNE-Python and load a first recording

The README gives the minimal-dependency install as a single pip command. Run it in a terminal, ideally inside a virtual environment, and you should end up with the mne package importable from that interpreter.

pip install --upgrade mne

The same section of the README points to the installation guide at mne.tools for standalone installers and more advanced methods, so if you need a bundled environment rather than a pip install, that is where the project sends you. The minimum Python version declared in the README is 3.11.

If you want the development version instead of the latest stable release, the README offers two routes. The first installs from a zip of the main branch, and the second clones the repository with git.

pip install --upgrade https://github.com/mne-tools/mne-python/archive/refs/heads/main.zip

git clone https://github.com/mne-tools/mne-python.git

Once installed, the first real step in any workflow is getting data into a Raw object through the io module. The exact reader function depends on your file format, and the README does not enumerate them; the io examples directory in the repository is the place to look for the format you actually have. From there, the tutorial material walks through filtering, channel handling and epoching. The Makefile also shows how the project itself pulls sample data, which is a useful hint that a standard dataset exists for following along:

python -c "import mne; mne.datasets.sample.data_path(verbose=True);"

That command downloads the sample dataset and prints its path. Expect a network fetch on first run.

Where MNE-Python gets in your way

The dependency floor is higher than many Python scientific packages. Python 3.11 or newer, NumPy 2.1 or newer, SciPy 1.14 or newer and Matplotlib 3.9 or newer are all required by the README's core list. On a locked-down cluster running an older Python, that alone can block adoption, and the answer is usually a conda environment rather than a system package upgrade.

The second constraint is scope. MNE-Python is a library, not an application. There is no graphical pipeline editor, and the README's support path is a user forum plus a GitHub issue tracker. If your lab's workflow depends on a technician opening files in a GUI and exporting a report, this is the wrong tool, and no amount of scripting will make it the right one for that person.

Third, the documentation surface is large and uneven by nature. The README itself is short and defers almost everything to mne.tools, and the repository's pyproject.toml shows a documentation build that pulls in mne-bids, mne-connectivity, mne-gui-addons, neo, openneuro-py, pymef, pyxdf and more. Those are separate projects with separate release cycles. When a tutorial fails, the cause is sometimes in one of those satellites rather than in MNE-Python itself, and the README gives no guidance on version compatibility between them.

MNE-Python against EEGLAB and MATLAB tooling

EEGLAB is the obvious comparison, and the difference is not just language. EEGLAB is a MATLAB toolbox built around an interactive GUI with a scripting layer underneath; MNE-Python is a Python library with a scripting layer on top and visualization functions you call explicitly. If your analysis is exploratory and you want to click through a dataset, EEGLAB's model fits better. If your analysis is a pipeline you will rerun on forty subjects, MNE-Python's model fits better, because the whole thing is code you can put under version control.

Within Python, the alternative is not a single package but a stack of narrower ones. MNE-Python's own documentation dependencies hint at this: mne-bids handles the BIDS data standard, mne-connectivity handles connectivity measures, mne-gui-addons handles interactive visualization. Those exist because MNE-Python deliberately does not absorb everything. Choosing MNE-Python means accepting that some adjacent concerns live in sibling packages maintained by overlapping but not identical groups.

A fair summary: EEGLAB gives you a workbench, MNE-Python gives you a library plus a set of conventions. Neither is a superset of the other, and the migration cost between them is real because the object models and the epoching conventions differ.

Maintenance, licensing and the cost of tracking releases

The repository is not archived, and the last push was on 2026-09-10. The most recent release listed is v1.13.0 on 2026-09-09, preceded by v1.12.1 on 2026-04-20 and v1.12.0 on 2026-04-07. That cadence, a minor release roughly every few months with patch releases in between, is what you should budget for. Pinning a version in your environment file is the practical move; floating on the latest release means re-validating your pipeline a few times a year.

The licence is BSD-3-Clause, stated plainly in the README and present as LICENSE.txt at the repository root. For most research and commercial use that is permissive: you can use, modify and redistribute the code with the copyright notice and disclaimer retained. It does not impose a copyleft obligation on your analysis scripts. This is a description of the licence text, not legal advice; if you are shipping a product that embeds the library, have your own counsel read LICENSE.txt.

Upgrade cost is dominated by API churn rather than by the licence. The project maintains a contributing guide and a pre-commit configuration, and the Makefile exposes targets such as test-doc and pre-commit for contributors. For users, the relevant discipline is simpler: read the release notes for the version you are moving to, and keep the environment pinned so that a transitive dependency bump does not silently change your numbers.

Editorial conclusion

Adopt MNE-Python if your pipeline is Python, your data is MEG, EEG, sEEG or ECoG, and you want source estimation, time-frequency and decoding in one library. Do not adopt it expecting a point-and-click GUI; the workflow is scripted, and the documentation points users to the installation guide rather than a wizard. Before committing, run pip install --upgrade mne in a clean environment and confirm that Python 3.11 or newer is available, since that is the floor the README declares.

Frequently asked questions

Official sources

1. License: BSD-3-Clause
2. mne-tools/mne-python on GitHub
3. Project website
4. README
5. Releases