July 12, 2026

MusicXML: How a Universal Format for Digital Sheet Music Emerged

What Is MusicXML?

MusicXML is an open format for representing and exchanging digital musical scores. It was designed primarily to move notation between different types of software: score editors, optical music recognition systems, digital music libraries, educational applications, and automatic transcription services.

The official specification describes MusicXML as an open standard for exchanging and archiving digital sheet music. Its current stable version is MusicXML 4.0, published in June 2021 by the World Wide Web Consortium and its Music Notation Community Group. At the time of its release, the standard was supported by more than 250 applications.

Unlike a PDF or an image, MusicXML preserves not only the visual appearance of a page but also the underlying structure of the music. A file may contain:

note pitches and durations;
measures, time signatures, and key signatures;
parts, staves, and voices;
rests, ties, tuplets, and other rhythmic structures;
dynamics, articulations, and ornaments;
tempo markings and performance directions;
lyrics, fingering, and chord symbols;
selected details of the score’s visual layout.

This means that a score can be displayed, edited, transposed, analyzed, played back, and converted into other formats.

MusicXML is built on XML — Extensible Markup Language, a text-based markup language in which data is represented through nested elements. A single note may contain information about its scale step, octave, duration, voice, staff, and notated value.

This structure makes MusicXML relatively easy to process and validate programmatically, although it also makes uncompressed files rather verbose.

Two file variants are commonly used:

.musicxml — a regular XML document;
.mxl — a compressed ZIP container containing the MusicXML document and, when necessary, related resources.

The compressed .mxl format was standardized in MusicXML 2.0. According to the specification, compressed files are typically around twenty times smaller than their uncompressed equivalents.

It is important to understand that MusicXML is not a complete substitute for the native project format of a score editor. Sibelius, Finale, Dorico, and MuseScore may store application-specific data and features inside their own project files.

When a score is exported to MusicXML, its main musical structure is usually preserved, but some layout settings, custom objects, and program-specific features may be lost or interpreted differently by another application.

MusicXML is therefore best understood not as a universal source format for every possible score, but as a shared language through which independent music applications can communicate.

A Chronology of Digital Music Notation Formats

Attempts to represent a musical score in a form suitable for computer processing began long before modern notation software.

These early systems were created for very different purposes: preparing printed music, analyzing musical structure, controlling electronic instruments, cataloging library collections, or transferring scores between applications.

The 1960s: DARMS and the First Machine-Readable Scores

One of the earliest major systems for representing musical notation on a computer was DARMS — Digital Alternate Representation of Musical Scores. Work on the system began in the first half of the 1960s, and it was presented publicly at a summer seminar in 1966.

The project was originally known as the Ford–Columbia Music Representation. It was funded by the Ford Foundation and developed at Columbia University.

The system was created by Stefan Bauer-Mengelberg for the preparation of performance materials for the New York Philharmonic.

Bauer-Mengelberg followed an unusually varied career. He worked as a mathematician at IBM, served as an assistant conductor to Leonard Bernstein at the New York Philharmonic, became president of Mannes College of Music, and later practiced law.

His combined background in mathematics and music allowed him to approach a musical score as a formal system of data.

One of the defining ideas behind DARMS was that scores could be entered by operators who did not know how to read conventional Western notation. Rather than identifying each note by name, an operator could simply count lines and spaces on the staff and then specify the duration and other visible characteristics.

Instead of note names, DARMS encoded vertical position on the staff. The bottom line was numbered 1, the space above it 2, the next line 3, and so forth. Durations were represented by letters:

W — whole note;
H — half note;
Q — quarter note;
E — eighth note;
S — sixteenth note.

A measure containing four ascending quarter notes can be illustrated schematically as follows:

Conventional notation:  E4  F4  G4  A4
                        ♩   ♩   ♩   ♩

DARMS, simplified: !G !M4:4 1Q 2Q 3Q 4Q /

Here, !G represents a treble clef, !M4:4 the 4/4 time signature, 1Q–4Q four quarter notes on successive staff positions, and / a barline.

This is a simplified illustration of the system’s general principle rather than a literal transcription of a particular example from the manual. The real DARMS syntax was considerably more complex and could encode voices, stem directions, ties, accidentals, beaming, dynamics, and ornaments.

Several dialects of the system existed, so the exact notation varied.

In 1964, musicologists Barry Brook and Murray Gould introduced the Plaine and Easie Code, a compact text-based method for recording musical incipits — the opening fragments of compositions.

Unlike DARMS, Plaine and Easie Code was intended primarily for library catalogs rather than the encoding of complete scores. Its modern version is maintained by the International Association of Music Libraries, Archives and Documentation Centres and the Répertoire International des Sources Musicales.

1967: SCORE and Professional Computer Music Engraving

In 1967, composer and Stanford University professor Leland Smith began developing SCORE.

The first version appeared at the Stanford Artificial Intelligence Laboratory as a music input language for the MUSIC V computer sound synthesis system. Smith later adapted it for music engraving.

SCORE was based on a parametric model. A score was represented as a collection of objects — notes, rests, clefs, barlines, slurs, and other elements.

Each object was described through numerical parameters defining such properties as pitch, duration, page coordinates, stem direction, and other visual characteristics.

The first printed results were produced with a plotter in 1971. During the 1980s, SCORE was ported to personal computers and developed into a professional publishing system.

It was used in the production of scholarly editions and valued for the precision it offered over music engraving.

The importance of SCORE lay not in its role as a universal interchange format, but in demonstrating that a computer could store highly complex musical notation and produce pages of professional publishing quality.

Its data language, however, remained closely tied to the software itself.

1983: MIDI — A Universal Language for Musical Performance

In the early 1980s, manufacturers of electronic instruments used their own mutually incompatible interfaces. A synthesizer made by one company could not easily communicate with a sequencer or drum machine produced by another.

To solve this problem, American and Japanese manufacturers jointly developed MIDI — Musical Instrument Digital Interface. The first MIDI specification was introduced in 1983.

Unlike DARMS and SCORE, MIDI was never intended to represent the visual page of a score.

It was a hardware and software protocol through which electronic instruments and computers could exchange instructions such as:

press or release a key;
specify a note number;
transmit key velocity;
change an instrument;
adjust volume, sustain pedal, or another controller;
synchronize several devices.

A simplified MIDI event may look like this:

Note On:  pitch=60, velocity=90
Note Off: pitch=60

The value 60 represents a particular pitch, while velocity=90 describes the intensity of the key press. MIDI records the performer’s actions and the timing between them, but it does not explain how those actions should be written in musical notation.

MIDI was originally a real-time communication protocol. The Standard MIDI File, commonly recognized by the extensions .mid and .midi, appeared later and made it possible to store sequences of MIDI events for transfer between sequencers and music applications.

MIDI became enormously successful because it was compact and interoperable. Files could be edited, sped up, transposed, and played using different instruments.

But MIDI does not preserve complete notational semantics. It generally lacks information such as:

the correct separation of voices;
the distinction between F♯ and G♭;
beaming patterns;
the exact written structure of note values;
most articulations and ornaments;
the position of objects on a printed page.

A performed duration may also differ from a written one. A pianist may release a quarter note early, delay the next note, or use the sustain pedal.

MIDI preserves these timing variations, but it does not reveal the notation from which the performance originated.

MIDI therefore became a universal language of performance, but not a universal format for the musical score.

The 1980s and 1990s: Academic Formats

In 1984, Walter Hewlett began developing MuseData, a system for encoding, printing, and archiving complete musical works.

MuseData represented parts, measures, durations, voices, and other components of musical structure. The same data could be used to generate a full score, extract individual parts, support computer analysis, or produce a performance.

At roughly the same time, musicologist David Huron was developing the Humdrum Toolkit, a collection of text-based formats and Unix tools for computational music analysis.

Humdrum files were organized into parallel columns known as spines. Each spine could represent a separate voice, part, or category of information: notes, harmony, text, or analytical annotations.

MuseData focused primarily on preparing and preserving high-quality score data, while Humdrum was designed for computational analysis.

Both projects later had a direct influence on the structure of MusicXML.

Finale and Sibelius: The Digital Score as a Closed Project

The first version of Finale appeared in 1988. It became one of the first widely used professional score editors for personal computers.

Finale allowed musicians to enter notation with a mouse or MIDI keyboard, edit large scores, play them back, and produce publication-quality pages.

Scores were stored in the program’s internal .mus format and, beginning with Finale 2014, in .musx.

These formats preserved musical structure, page layout, and application-specific objects, but were intended primarily for use inside Finale.

Development of Sibelius began in 1986. The program was created by brothers Ben Finn and Jonathan Finn for the Acorn Archimedes computer.

The first commercial version of Sibelius was released in 1993. The software was later ported to Windows and macOS.

Sibelius stored scores in its proprietary .sib format, likewise closely tied to the application’s internal data model.

By the end of the 1990s, computers could store and print scores of extraordinary complexity. Yet every major program had developed its own internal representation of music.

A Finale score could not be opened reliably in Sibelius, and a Sibelius file could not simply be transferred into another publishing system.

MIDI was often used as an intermediary, but voices, ties, articulations, enharmonic spelling, and most layout information were lost. PDF preserved the page, but reduced the score to an essentially non-editable document.

The central problem was no longer how to represent music inside a computer. It was how to move a structured score from one program to another.

The 1990s: SMDL and NIFF

One of the most ambitious attempts to create a common standard was SMDL — Standard Music Description Language, adopted as the international standard ISO/IEC 10743.

SMDL attempted to describe several layers of music at once: its logical structure, visual representation, performance, and analytical data.

The format was based on SGML — Standard Generalized Markup Language and HyTime, a standard designed to represent complex temporal and hypermedia relationships.

In theory, this made SMDL extremely powerful. In practice, it made the system too broad and too difficult for most developers to implement.

Despite its status as an ISO standard, SMDL was never adopted by a mainstream commercial music application.

A more practical attempt was NIFF — Notation Interchange File Format. Development began in 1994, and the specification was distributed in August 1995.

NIFF was intended for the exchange of data between score editors, publishing systems, and optical music recognition software.

It could preserve information at several levels of detail, from basic pitch and duration data to exact page positioning, graphics, and embedded MIDI information.

NIFF was a binary format built on RIFF — Resource Interchange File Format, in which data was stored in separate blocks known as chunks.

NIFF received some support from optical music recognition systems because its graphical model matched the type of information produced by scanning software.

For other music applications, however, that same graphical orientation proved cumbersome. According to Michael Good, the creator of MusicXML, scanning applications were the only category of software to adopt NIFF to any meaningful extent.

SMDL and NIFF revealed two opposite problems.

SMDL attempted to construct a theoretical model that was too universal, while NIFF was too heavily oriented toward the graphical placement of symbols.

A future standard would need to strike a balance: sufficiently expressive for professional notation, yet simple enough to be implemented by developers of ordinary music software.

2000: The Birth of MusicXML

By the end of the 1990s, many methods for representing music on computers already existed, yet none solved the practical problem of score exchange particularly well.

MIDI described performance. The native formats of Finale and Sibelius were closed. SMDL was too complex, while NIFF never spread far beyond optical music recognition.

In 2000, software developer Michael Good founded Recordare to create a new interchange format: MusicXML.

Unlike SMDL, the project did not attempt to build a complete model of every kind of music ever created. Its purpose was practical: to transfer conventional Western music notation between real-world applications.

In the 2001 presentation MusicXML: An Internet-Friendly Format for Sheet Music, Michael Good described the format as a universal translator for common Western notation.

Why XML?

By the beginning of the 2000s, XML had already become a widely used open standard for structured data. Parsers, validation tools, and libraries were available for virtually every major programming language.

Instead of inventing another proprietary binary container, MusicXML could rely on an existing technical ecosystem.

A file could be opened in an ordinary text editor, while its structure could be validated using a DTD or XML Schema.

Its elements were given clear musical names:

<note>
<pitch>
<measure>
<duration>

The format favored clarity over compactness. Files were large, but their structure was comparatively easy for a developer to understand.

MuseData and Humdrum as Foundations

MusicXML was not designed from scratch. Its earliest versions were essentially a translation of the MuseData model into XML, supplemented by important ideas from Humdrum.

MuseData had already been used for complete classical scores and could interoperate with MIDI. Humdrum contributed ideas for representing parallel musical data and supporting computational analysis.

MusicXML was later expanded to cover popular music, tablature, and other forms of notation that had not been central to the original academic systems.

A Format Developed Alongside Real Software

Recordare did not merely publish a specification. MusicXML was designed in parallel with working conversion tools.

Early prototypes included:

conversion from MuseData to MusicXML;
conversion from NIFF to MusicXML;
conversion from MusicXML to MIDI;
export from Finale ETF to MusicXML.

This allowed design decisions to be tested immediately on real scores and revealed musical structures that the format still failed to represent adequately.

In September 2001, SharpEye Music Reader, developed by Graham Jones, became the first commercial application to support MusicXML.

The Dolet technology developed by Recordare was subsequently included in the Windows version of Finale 2003.

This created a genuine working pipeline: a score recognized in SharpEye could be transferred into Finale with far greater accuracy than was possible through MIDI.

Support from one of the market leaders became a crucial factor in the further adoption of the standard.

Commercial applications began using MusicXML 0.5 as early as 2001, but MusicXML 1.0 was not released until January 2004.

The developers deliberately avoided freezing the standard too early. It was first tested across score editors, scanning systems, sequencers, educational software, and other real-world applications.

MusicXML succeeded not because it was the most comprehensive or theoretically perfect format.

It succeeded because it was expressive enough for professional scores, understandable enough for software developers, and accompanied from the beginning by practical tools for widely used applications.

The Development of MusicXML

2001 — MusicXML 0.5. The first commercial implementations and public presentation of the format.
January 2004 — MusicXML 1.0. The first stable release of the specification.
May 2005 — MusicXML 1.1. Major improvements to score layout, including page, system, staff, scaling, font, and positioning information.
June 2007 — MusicXML 2.0. Introduction of the standardized compressed .mxl format, together with new support for graphics, playback, and interactive score distribution.
August 2011 — MusicXML 3.0. Expanded support for virtual instruments, standardized sounds, percussion, tablature, and playback parameters.
2011 — MakeMusic acquired Recordare. Development of the specification continued within the company.
July 2015 — development moved to the W3C Music Notation Community Group. The group assumed responsibility for documenting, maintaining, and developing both MusicXML and SMuFL — Standard Music Font Layout.
December 2017 — MusicXML 3.1. The format moved to a W3C license, .musicxml became the recommended extension for uncompressed files, and integration with the SMuFL music symbol standard was expanded.
June 2021 — MusicXML 4.0. A standardized method was introduced for storing both a full score and individual parts inside a single .mxl file. The XML schemas were updated, and new elements were added for playback, harmonic analysis, and score-following systems.

Conclusion

MusicXML did not replace the native formats of notation software, MIDI, or PDF.

Instead, it occupied a distinct space between them: it became the standard way to transfer a structured, editable score from one application to another.

The history of MusicXML demonstrates that a successful standard does not need to describe every possible form of music.

It needs to solve a specific practical problem more effectively — and more simply — than the systems that came before it.

References

World Wide Web Consortium. MusicXML 4.0: Final Community Group Report. W3C Music Notation Community Group, June 1, 2021.
World Wide Web Consortium. MusicXML 4.0: Introduction. Official introduction to the purpose and scope of the format.
World Wide Web Consortium. MusicXML Version History. History of MusicXML versions 1.0 through 4.0.
World Wide Web Consortium. Extensible Markup Language (XML) 1.0. Official XML specification.
Library of Congress. MusicXML File Format Family. Description of the format, its history, openness, interoperability, and archival suitability.
Good, Michael. Lessons from the Adoption of MusicXML as an Interchange Standard. Proceedings of XML 2006, Boston, 2006.
Good, Michael. MusicXML: The First Decade. A history of the design and first ten years of MusicXML.
Good, Michael. MusicXML: An Internet-Friendly Format for Sheet Music. Proceedings of XML 2001.
Good, Michael. The Need for a New Music Interchange Format. A comparison of MusicXML with MIDI, NIFF, and earlier interchange formats.
Erickson, Raymond F. DARMS: A Reference Manual. Binghamton, New York, 1976.
Center for Computer Assisted Research in the Humanities. DARMS. History of the Digital Alternate Representation of Musical Scores.
Bauer-Mengelberg, Stefan. Recollections. Biographical information concerning his work at IBM, the New York Philharmonic, and Mannes College of Music.
Brook, Barry S.; Gould, Murray. Plaine and Easie Code. History and modern specification of the library format for musical incipits.
Stanford University. Stanford Professor Leland Smith, Innovative Music Creator, Dies at 88. Biography of the creator of SCORE and an overview of his work in computer music engraving.
Center for Computer Assisted Research in the Humanities. Music 253: SCORE. History of SCORE and early computer music engraving.
The MIDI Association. MIDI History: MIDI Begins, 1981–1983. Official history of the development of MIDI.
Library of Congress. Standard MIDI File Format. Technical and historical description of .mid and .midi files.
Center for Computer Assisted Research in the Humanities. MuseData. History and purpose of Walter Hewlett’s system.
Huron, David. The Humdrum Toolkit for Computational Music Analysis. Documentation and history of Humdrum formats.
Library of Congress. Finale Music Notation File. History of Finale and its .musx format.
Library of Congress. Finale Legacy Music Notation File. Description of Finale’s legacy .mus format.
Library of Congress. Sibelius Music Notation Format. History of Sibelius and its proprietary .sib format.
International Organization for Standardization. ISO/IEC 10743: Standard Music Description Language. International SMDL specification.
Grande, Cindy. The Development of the Notation Interchange File Format. Computer Music Journal, vol. 20, no. 4, 1996.
Notation Interchange File Format Project. NIFF Specification: Introduction. Description of the purpose and structure of NIFF.
W3C Music Notation Community Group. Music Notation Community Group. Official page of the group responsible for MusicXML and SMuFL.