Making music in the browser: what browser DAWs can and cannot do

A browser DAW is now a real option for a lot of music making. You open a tab, there's nothing to install, and you can send a collaborator a link. But "it runs in a browser" covers several separate technical limits, and those limits decide whether a browser DAW suits your workflow. This guide explains the parts of the web platform these tools are built on, what each part allows, and where you'll still want a desktop DAW.

If you just want to know which free browser DAWs exist and what their free plans include, read our desk review of free browser DAWs. This piece is about the platform underneath all of them.

The engine: Web Audio and AudioWorklet

Every browser DAW sits on the Web Audio API, a W3C specification that is still a Working Draft on the Recommendation track (W3C). It gives web pages a graph of audio nodes, including oscillators, filters, gain stages and sample players, which the browser processes for you.

The big change in recent years is the AudioWorklet. It lets a DAW run its own audio code (a synth, a compressor, a whole mixer) "in a separate thread to provide very low latency audio processing", and MDN reports it "has been available across browsers since April 2021" (MDN, AudioWorklet). Before that, custom processing had to share a thread with the page's interface, so a busy screen could cause dropouts. Now audio has its own lane, which is why recent browser DAWs feel much steadier than browser music toys used to.

The engine works in small fixed blocks. The specification's default render quantum is 128 frames (W3C). At a 48 kHz sample rate that's about 2.7 ms of audio per block. That block is not your total latency, but it does show that the engine itself isn't the bottleneck.

Latency: where the delay actually comes from

Latency is the gap between playing a note and hearing it. Our latency and buffer size guide covers this for desktop DAWs. In the browser you get less control over it.

When a DAW creates its audio engine (an AudioContext), it can only ask for a latency. The latencyHint option takes "interactive" (the default: "the lowest possible latency that doesn't cause glitches"), "balanced", "playback", or a number in seconds. MDN warns that "the user agent may or may not choose to meet this request" (MDN, AudioContext()). The browser also reports an outputLatency, the time between handing audio to the operating system and the first sample reaching the output device, and MDN notes it "varies depending on the platform and the available hardware" (MDN, outputLatency).

In a desktop DAW you choose the buffer size and the driver. In a browser, the browser and the operating system choose, and the DAW can only make a request. In practice:

• Programming beats, editing and mixing are fine. A few extra milliseconds don't matter when you click notes into a grid.
• Playing a soft synth live is usually workable on a wired setup. Bluetooth headphones add their own delay on top of anything the browser does.
• Recording while monitoring through the DAW is the hardest case. If your audio interface has direct (zero-latency) monitoring, use it and keep the browser's monitoring off.

One more browser rule: Chrome creates an AudioContext in a "suspended" state if the page makes it before you interact with the page. Audio starts only after a click or key press (Chrome for Developers). That's why so many browser DAWs open with a "click to start" screen. It's normal, not a bug.

Recording: switch off the call-quality processing

Browsers get microphone access from the same system that powers video calls, and calls want echo cancellation, automatic gain control and noise suppression. Browsers let a page specify whether each of these is on (MDN, echoCancellation). For music you want all three off. Otherwise a sustained vocal can get ducked or smeared, and quiet room tone can get gated out.

What to check before a serious take:

• Look in the browser DAW's input settings for an option like "raw input" or "disable processing", and turn it on if it exists.
• Record a test: sing a long note, then stop and leave a quiet tail. If the level pumps or the tail gets cut off, processing is still on.
• Choose your audio interface as the input explicitly. The system default is often the laptop mic.

MIDI: check your browser first

Hardware controllers reach a browser DAW through the Web MIDI API. MDN marks it as not Baseline, because it "does not work in some of the most widely-used browsers". It also needs a secure (HTTPS) page and your explicit permission (MDN, Web MIDI API). If your keyboard does nothing, check MDN's compatibility table for your browser before blaming the cable, and look for a blocked permission prompt in the address bar. Our MIDI controller basics covers the hardware side.

Plug-ins: the biggest gap

Your VST3 and AU plug-ins are native desktop programs. A web page can't load them directly. Browser DAWs offer three approaches:

1. Built-in instruments and effects only. Each tool ships its own synths and processors, written for the web. This works everywhere, but you're limited to what that tool includes.
2. A desktop bridge. A small helper app on your computer runs your native plug-ins and streams audio to the browser. Audiotool's comparison page, for example, lists "VST3 (via Bridge)" for third-party plug-ins on its free plan (Audiotool). You get your own plug-ins back, but you need an install, so the "nothing to install" advantage is gone, and that part of the session only works on the machine running the bridge.
3. Bounce and move on. Print the part with the plug-in in your desktop DAW and import the audio. It's clumsy, but it always works.

If your sound depends on a particular third-party synth or a paid mastering chain, approach 1 won't cover it. Plan for 2 or 3 from the start.

Storage: the browser can delete your projects

This catches people out more than any other limit. Many browser DAWs save projects to your account in the cloud, but some keep audio or drafts in the browser's own storage. WebKit, the engine behind Safari, "deletes all cookies created in JavaScript and all other script-writeable storage after 7 days of no user interaction". That includes IndexedDB and LocalStorage, and home-screen web apps are exempt (WebKit). So a project you saved locally in Safari and then left for a week and a bit may not be there when you return.

The fix is simple: find out where your DAW saves (account cloud or local browser storage), export stems or a project file at the end of each session, and follow our project backup routine.

A workflow that plays to the strengths

• Sketch in the browser. Ideas, beats, arrangements and quick demos, on any computer, including one that isn't yours.
• Collaborate by link. Shared projects are where browser DAWs most clearly beat desktop software.
• Record with direct monitoring and processing off. Check with a test take before the real one.
• Finish where your plug-ins live. Export stems (WAV, at the project's sample rate) and do the final mix in whichever environment has your tools.
• Export every session. Never let the browser's own storage be the only copy.

Browser tools that add an AI co-producer, like Veena (made by our parent company), sit on the same platform, so the same limits on latency, MIDI, plug-ins and storage apply to them too.

What we think

The usual way people compare browser DAWs with desktop DAWs ("is it as good as Logic?") misses the point. The engine is no longer the problem: audio runs on its own thread in blocks of a few milliseconds. The real limits are about who controls your setup and your files. The browser decides your latency, which MIDI APIs you can use, and whether local storage survives a week. That's a big trade for artists, and tools should be upfront about it.

So we'd judge any browser DAW on three questions before looking at a single feature. Can I export everything, stems and project, in open formats whenever I want? Does it tell me plainly whether my work is stored on its servers or in my browser? Does it turn off call-style input processing by default when I record? A tool that answers yes to all three treats your music as yours. One that keeps your work inside its tab, however clever it is, is asking you to trust it with your catalogue. Start in the browser for speed and collaboration, keep your masters somewhere you control, and pick the tools that make that easy.