# Web Audio Samples, the Chrome team's reference gallery for the Web Audio API > GoogleChromeLabs/web-audio-samples is the source of the Web Audio Samples site, a curated set of small projects built by the Chrome Web Audio team to show what the browser's audio stack can do, from basic synthesis to audio worklets and MIDI. The site is built with Eleventy and Tailwind, and the tests run under Playwright. **GoogleChromeLabs/web-audio-samples** — Web Audio API samples by Chrome Web Audio Team - Repository: https://github.com/GoogleChromeLabs/web-audio-samples - Website: https://bit.ly/web-audio-samples - Stars: 758 · Forks: 208 - Language: JavaScript - License: Apache-2.0 - Published: 2026-10-21 · Updated: 2026-10-21 · Language: en - Canonical page: https://hysenlabs.com/projects/googlechromelabs-web-audio-samples ## What the site is and who maintains it The Web Audio Samples site collects projects, examples and resources for the Web Audio API, curated by the Chrome Web Audio team. The repository holds the source of that site, and the built site lives on the gh-pages branch, with the short link bit.ly/web-audio-samples pointing at it. The branch structure explains how the project is organised. The main branch is the site source. The gh-pages branch is the actual site built from main. The archive branch holds the old projects and examples, described as V2 and earlier, which is a useful distinction for anyone who arrives at a sample reference and finds the current set is much smaller than they expected. The audience is developers who want to see a specific pattern working rather than read about it. The Web Audio API is large enough that its specification examples cover the shape of the API but not the feel of it, and the value of a curated gallery is that each entry is small enough to read in one sitting and complete enough to run. The support path is a GitHub issues tracker, and the contribution guidance asks for patches through pull requests, with CONTRIBUTING.md carrying the detail. The project is not archived and the last push was on 2026-10-16, so the samples are still being maintained as the API evolves. The copyright is 2018 Google, Inc. and the README states the Apache License version 2.0, with the standard notice and the URL of the licence text. There is a discrepancy worth flagging: the package.json in the repository declares the licence as MIT, while the README and the LICENSE file are Apache-2.0. For a project with both statements, the LICENSE file and the copyright line are the more authoritative of the two, but if you copy code out of it, the safest assumption is that the terms are the ones in the README. ## How the site is built The build is a static site generated with Eleventy, and the package.json scripts show the pipeline clearly. The build script runs three steps in order: clean, which removes the _site directory with rimraf, build:css, and build:eleventy. The CSS step runs the Tailwind command line tool over ./src/styles/styles.css and writes a minified styles.css into the site, and the Eleventy step runs with ELEVENTY_ENV=production set. The development server is the same thing without the production flag and with watching. The start script runs the CSS build in watch mode and the Eleventy server in parallel using npm-run-all, and the two Eleventy plugins in the dependencies are the core one and the navigation plugin, which is what generates the sidebar for a gallery with dozens of entries. The lint setup is eslint 10 with a flat config in eslint.config.mjs and the shared configs from @eslint/js and the globals package. The format script runs lint:fix, and the README is explicit that you should run npm run format to apply linting and formatting before you commit. There is a Playwright dependency and a playwright.config.ts at the repository root, with two test scripts. The first serves the built site with a plain http-server. The second, test:live, serves the playwright pages directory directly, which suggests there is a set of pages written specifically for the browser tests rather than the samples themselves. The main test script is deliberately disabled, and the reason is given: Test disabled due to issue #426. That is an honest thing to find in a package.json, and it tells you the test suite exists but is currently switched off, so a failing test will not stop a build. There is one more script that is worth noticing because it shows how a sample with its own build gets handled. The rainfly script changes into the src/rainfly directory and runs its build there, which is the pattern for the samples that need a bundler of their own rather than being served as plain files. ## What the samples cover and what to expect from them The repository description calls the collection a set of projects, examples and resources, and the topic list gives the shape of the coverage: audio, audio worklet, the Web MIDI API, Chrome and the Web Audio API itself. The audio worklet samples are the part that matters most for anyone building something real. The AudioWorklet API is where the Web Audio API stops being a set of built-in nodes and becomes a programmable synthesis engine, and it is also the part with the least hand-holding in the specification. A working example of an AudioWorklet processor, with the processor code and the page that loads it, answers questions that the specification leaves you to work out. The Web MIDI API samples cover the other direction, from a web page sending and receiving MIDI messages to hardware. That API is less about audio processing and more about connecting to external instruments and controllers, and it has a similar problem: the specification describes the messages and the examples in the documentation are minimal. What the samples are not is a library. The README describes them as projects and examples, and the version in package.json is 3.3.0 for the site itself rather than for a published API surface. There is no stability guarantee, no semantic versioning commitment for the code, and no changelog to consult. That matters when you copy from them: treat the code as a starting point to adapt rather than a dependency to depend on. The other thing to expect is that a sample is a demonstration of one idea, not a complete application. Several of them will assume a particular sample rate, will not handle the case where the browser suspends the audio context, and will not bother with the error paths. Reading them as illustrations of an API and running them as-is are two different activities, and the second one is where the disappointment comes from. What they are good for is the moment when a specification paragraph is not enough and you need to see the wiring: how the context, the source nodes, the destination node and the parameters connect, and what a worklet processor looks like when it is actually loaded. ## How to work through them and what to compare against The development loop is five steps, and it is short enough to do before you read anything else. Clone the repository, run npm install, run npm run start to fire up the local dev server, run npm run format to apply linting and formatting, and then npm run deploy when you want to publish. Running locally rather than reading the live site is worth the extra minute, because the local server gives you the source of the sample you are looking at in the same window as its output, and the samples reference files that are easier to follow when the paths resolve locally. The alternative to this gallery is the Web Audio API specification itself, together with the examples in the Chrome developers documentation. The specification is authoritative and complete, and it is where you should go to find out what a parameter means. The samples are better for understanding how a working piece fits together. The second alternative is the AudioWorklet examples that ship with the Chrome developer documentation, which are close in spirit to these and are the ones to check first if your question is narrow, since they are maintained alongside the browser rather than alongside a site. There is also a broad category of Web Audio libraries, the synthesis frameworks and the spatial audio tools, which offer far more than these samples do. If you are building a synthesiser, a plugin host or a spatial audio engine, a library is the right dependency and this gallery is where you look after you have read its documentation. The practical sequence that works is: run the local site, open the sample closest to what you are building, read its source rather than only running it, then check the specification for the parameters it uses, and only then write your own version. That last step matters, because the samples demonstrate the API but they do not teach the engineering, and the difference shows up in error handling, in what happens when the audio context is suspended, and in how you handle a device being unplugged mid-session. ## Conclusion Adopt these samples as a reference when you are learning the Web Audio API or need a working example of a particular pattern, especially audio worklets and MIDI handling that the specification examples do not cover. Skip it if you need a production library, since these are demos without an API contract. Verify first by running npm install and npm run start, then open a sample in a browser with a recent Chromium, since a few of them depend on features that are not yet in every browser. ## FAQ ### What is the Web Audio Samples repository? It is the source of the Web Audio Samples site, a collection of projects, examples and resources for the Web Audio API curated by the Chrome Web Audio team. The main branch holds the site source and the gh-pages branch holds the built site. ### How do I run the Web Audio Samples site locally? Clone the repository, run npm install, then npm run start to launch the development server, which runs the Tailwind CSS build and the Eleventy server in parallel. Run npm run format to apply linting and formatting before you commit. ### What technology does the Web Audio Samples site use? Eleventy for the static site generation, with the navigation plugin for the sidebar, and Tailwind CSS for the styling built through its command line tool. The linting is eslint 10 with a flat config, and the browser tests use Playwright. ### Are the Web Audio Samples tested in continuous integration? The main test script is disabled, with the reason given in the package.json as Test disabled due to issue #426. There is a separate live test script that serves the Playwright pages directory with http-server, so a test setup exists even though it is currently switched off. ### What licence applies to the Web Audio Samples code? The README states Apache License version 2.0 with a 2018 Google copyright, while the package.json declares MIT. If you copy code out of the project, the README and LICENSE file are the more authoritative statement of the terms. ## Sources - [GoogleChromeLabs/web-audio-samples on GitHub](https://github.com/GoogleChromeLabs/web-audio-samples) - [Issues](https://github.com/GoogleChromeLabs/web-audio-samples/issues) - [License: Apache-2.0](https://github.com/GoogleChromeLabs/web-audio-samples/blob/main/LICENSE) - [Project website](https://bit.ly/web-audio-samples) - [README](https://github.com/GoogleChromeLabs/web-audio-samples/blob/main/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/googlechromelabs-web-audio-samples