Verovio engraves MEI scores into SVG from C++

One library, one output format

Verovio is described as a fast, portable and lightweight library for engraving Music Encoding Initiative digital scores into SVG images, and that single sentence defines the project. The input is MEI, the Music Encoding Initiative format, and the output is SVG, which is a choice with consequences. Because the output is vector graphics rather than a raster image, the result scales to any size, which is what makes it usable in a browser at any zoom level and in print at any resolution, and the SVG can be styled and post-processed. The phrase lightweight is doing real work too, since the library is compiled C++ rather than a script, and a renderer that runs inside a web page has a size budget. The project is hosted under the RISM Digital organisation, which is the research institute behind the RISM music libraries, so the use case behind it is scholarly digital music.

Converters for the formats that arrive in practice

Beyond MEI, Verovio contains on-the-fly converters for several other digital score formats, and the list is the practical argument for using it. The formats are Plaine and Easie Code, Humdrum, Musedata, MusicXML, EsAC and ABC notation. The word on-the-fly matters, because it means you can hand the library a MusicXML document and get an SVG back without running a separate converter and without a round trip through a file. For a digital library that ingests scores from many archives in many formats, that is the feature that decides the question. ABC notation in particular is worth calling out, because it is the format people actually type into, and a converter that renders it properly turns a text file into a usable score.

C++20 underneath, a binding on top

Verovio is written in standard C++20 and is available in several bindings, for JavaScript, Python, Java, Swift and Go. It can be compiled as a standalone command-line tool or as a music-rendering library for applications, and the choice matters for deployment, since a command line tool fits a batch pipeline and a library fits an interactive application. The JavaScript toolkit version runs in the Verovio Online Editor and Viewer, and the tutorials cover web integration and user interaction. The minimal sample applications section points at three reference projects that show the same library in three different shapes, a C++ with Qt project, a Java binding on Android and a Swift binding on iOS, both of the latter two published to their app stores. That set is a good template for anyone embedding an engraver in a native application.

The font is part of the contract

Verovio uses the Standard Music Font Layout specification, and the font can be changed to personalise the output. This is a small line in the README with a large consequence, because engraving is a font problem as much as a layout problem. The glyph shapes, the metrics and the way beams and flags are drawn all come from the font, and the SMuFL specification is what makes it possible to swap fonts and still get correct spacing, because the metrics are defined rather than drawn into the renderer. For a library that renders scores for a digital edition, that means the typography can be adapted to the period of the source material, and the fonts/ directory in the repository is where those choices live.

Embedded libraries and generated attribute classes

The library embeds a handful of third-party components, and the table of what they are for is short enough to be worth reading. humlib handles Humdrum file import and export, JSON++ is the JSON parser, MidiFile handles standard MIDI file export, pugixml is the XML parser, MINIZ-CPP reads and writes ZIP files, and the tuning library from the Surge Synth Team provides the tuning data. Underneath, the attribute classes of Verovio are generated from the MEI schema using a modified version of LibMEI, and the generated code is included in the Verovio repository so that the LibMEI repository does not need to be cloned for a build. That is a thoughtful packaging decision, because the alternative is a build that requires a second repository at a matching revision, and generated code checked into the tree is the pattern most C++ projects with schema-driven code use.

The Python binding is scikit-build-core and SWIG

The Python packaging shows how the bindings are produced. The build backend is scikit-build-core with SWIG in the build requirements, and the project metadata declares the version dynamically, requires Python 3.10 or newer, and marks the licence as LGPL-3.0-only. The scikit-build section points the CMake source directory at the cmake directory, defines BUILD_AS_PYTHON, and sets the wheel Python API to cp310. The sdist include list names the directories that matter, bindings/python, cmake, data, include, libmei, src and tools, and the exclude list removes the build leftovers such as the generated Python module and the static library. The wheel configuration is done with cibuildwheel, and the details are the kind that matter in practice, with the manylinux2014 image used for both x86_64 and aarch64, SWIG installed in the before-all step, several platform and architecture combinations skipped, and a smoke test that runs the Python documentation test script.

Licence, releases and the current state

Verovio is available under the LGPL licence, with the COPYING and COPYING.LESSER files in the repository, and the Python metadata records it as LGPL-3.0-only. The releases are version 6.3.0 from 2026-08-19, 6.2.1 from 2026-05-22 and 6.2.0 from 2026-05-20, and the default branch is develop rather than main, so the code on the default branch is ahead of any tagged release. The repository is not archived and the last push was on 2026-10-19. Around the source there is the usual apparatus of a mature project, with a podspec and an Xcode project for the Swift binding, a Package.swift, a bindings/ directory, an emscripten/ directory for the WebAssembly build, a cmake/ directory, a data/ directory for the resources, and a codemeta.json for citation metadata alongside a Zenodo DOI. The continuous integration runs on both GitHub Actions and AppVeyor.

Editorial conclusion

Verovio fits a digital music project that has MEI as its interchange format and needs consistent, high quality engraving in a browser, and the fact that it is a compiled C++ library with a thin binding layer is what makes the rendering fast in a web page. It does not fit a project that only needs to show a tune, since a full engraving engine is a heavy dependency, and it does not fit someone who cannot use the SMuFL font requirement. Before you integrate it, check which input formats you actually have, because the converters are a large part of the value, and note the release state, where 6.3.0 was published on 2026-08-19 and the last push was on 2026-10-19.

Frequently asked questions

Official sources

1. License: LGPL-3.0
2. Project website
3. README
4. Releases
5. rism-digital/verovio on GitHub