WebAudioFont: sample-based GM instruments in a plain HTML5 browser

Sample-based synthesis without plugins or Flash

Playing a convincing piano in a browser used to mean a plugin, an embedded Flash player, or a download. WebAudioFont takes a different route. It is described as a set of resources and associated technology that uses sample-based synthesis to play musical instruments in the browser, and the project description emphasises that there are no plugins and no Flash, with a pure HTML5 implementation compatible with desktop and mobile browsers. That last part matters more than it sounds. A sampler that only works on desktop leaves out the majority of your audience, and the project treats mobile support as part of the baseline rather than an extra. The intended users are web developers who want musical instruments in a page: educational software with playable keyboards, music toys, MIDI players, and anything that needs a General MIDI sound palette without asking the user to install anything.

A catalog of thousands of instruments, with GM compatibility

The catalog is the resource half of the project. You can choose from thousands of instruments, and the package description puts the number at about 2000 musical instruments with GM MIDI compatible. General MIDI compatibility is the design centre here, because a MIDI file written against the GM standard will produce the intended instrument on any GM system. The npm package is named webaudiofont, sits at version 3.0.04, and its main entry point is npm/dist/WebAudioFontPlayer.js. The repository layout shows the pieces: a build directory, an npm directory holding the distributed code and the API documentation, an examples directory with one page per feature, an img directory for assets, and a _config.yml, which is the configuration for the GitHub Pages site that hosts the live examples. That site is where you can actually try the library without installing anything.

The example gallery as the documentation

The project teaches through runnable pages rather than prose, and the list in the project documentation doubles as a feature map. There is a simple example, a virtual drums page, a virtual piano, an endless flute, a two voices example, sound effects, realtime music, dynamic loading, a mixer with equalizer and reverberation, a custom AHDSR envelope, a strum chord page, a MIDI keyboard, and a MIDI player. Each of the first few comes with a link to editable code as well as a link to the running example. That pattern tells you something about the intended integration: you drop a page into your own project, point it at a soundfont, and you get a playable instrument. The MIDI keyboard and MIDI player pages are the most directly useful for application work, since they cover input and file playback. The mixer page is the one to study if you care about output, because reverberation and equalisation are the two processing features the project advertises.

Reverberation, equalisation, and the AHDSR envelope

Two audio processing features are called out in the project description: reverberation and equaliser. Together with the mixer page they suggest a signal chain of load instrument, shape it, then treat the output. The AHDSR example goes further into the instrument side. AHDSR stands for attack, hold, decay, sustain, and release, the envelope stages of a synthesised voice, and the example page shows a custom envelope being applied. So the library is not only a sample player with a fixed envelope per preset, it exposes envelope control, which is what turns a preset sound into something playable as an instrument rather than a one-shot sample trigger. A dedicated customsample example also exists in the examples directory, alongside a builder page, which suggests you can bring your own samples into the same chain.

Applications built on top: pianoroll, fretboard, accompaniment, sequencer

The project documentation lists example applications that show how far the library can be pushed. A pianoroll editor is offered as a web version and as an Android app, and the web version is launched with a long encoded riff parameter in the URL. A fretboard for chords is a second application, again launched with encoded riff data. An auto accompaniment project lives in a separate repository named rockdice, and a 3D music sequencer is launched from a parse page with another encoded riff string. The riff encoding is worth noting as a design idea rather than an accident. A single URL carries the whole musical content, which makes it easy to share a piece of music as a link instead of as a file, and it explains why these pages can be launched directly from a documentation link with no setup.

GPL-3.0 and the request for a different licence

The licence is the most consequential fact in this project for anyone shipping a product. The repository is licensed under GPL-3.0, the package manifest records the licence as GPL-3.0-or-later, and the licence text lives in the LICENSE.md file. The project documentation also states plainly that you should contact the author if you need a different licence, and it offers paid help for advanced assistance. GPL-3.0 is a copyleft licence, so distributing a derivative work in a closed source product carries obligations that this documentation does not spell out, and nothing here is legal advice. The practical options are to comply with the GPL terms, to seek a different licence from the author, or to use the library in a way that does not require you to distribute a derivative work. That decision belongs to your legal team, but it should be made before you build anything, not after, because the licence terms apply to the whole work.

Maintenance state and how to start using it

The repository is not archived and the last push was on 2026-09-04, so the code is being worked on, although there are no GitHub releases at all, which means there is no tagged version to pin to and the version number in the manifest is the only version marker. The package manifest itself is minimal. The test script is a placeholder that echoes test, and there is a TypeScript build step run through tsc against npm/src/tsconfig.json, with typedoc as the only declared dependency and used for the API documentation. That build directory is where the documentation under npm/src/docs that the API link points to comes from. Practically, there are two ways in. The fastest is the live examples on the project site, which need no tooling at all and let you hear what the instruments sound like before you commit. The second is the npm package, whose main entry is npm/dist/WebAudioFontPlayer.js, and the wiki is the place to look for integration guidance that the examples do not cover.

Editorial conclusion

WebAudioFont fits web projects that need real instrument timbres rather than oscillator beeps, especially MIDI players, educational tools, and browser experiments that need General MIDI compatibility without a plugin install. It is the wrong choice for a closed source product unless you are willing to deal with the GPL-3.0 obligations, and the wrong choice if you need a server side or native audio pipeline, since this is a browser technology. Before adopting it, read LICENSE.md directly, because the project description asks you to contact the author if you need a different licence, and confirm that the soundfont files you plan to load are reachable from your deployment, since the player fetches them over the network.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. Project website
4. README
5. surikov/webaudiofont on GitHub