A few months ago I put out ezaudio. It's a small set of audio tools, a vocal remover, a stem splitter, and an audio to text thing, and the whole point is that you use it straight from your browser. No app to install, no desktop setup. You open a tab, drop a file in, and get the result back.
I'm not here to sell it. The link is at the bottom and I'll say so plainly. I just want to talk through what building this actually taught me, because a lot of it I had to learn the hard way.
Why even put audio tools in a browser
The easy answer is the one everyone gives. No install step. Anything with a browser is a supported platform, so you skip the entire nightmare of building native apps for every OS. For one person or a tiny team that matters more than people admit. It's the difference between shipping and not.
But the reason people actually kept using mine wasn't the convenience alone. It was the zero friction entry. No downloads, no account wall, no "which version runs on my machine" questions. That low barrier is the whole reason a tool like this gets tried at all. I almost treated that as a footnote early on and that was a mistake.
The tradeoff is real though. You're at the mercy of the network and the backend. Every request has latency, and a flaky connection means a flaky product. You don't get to pretend the heavy work is free.
The browser is the front door, not the engine
This bit tripped me up. The Web Audio API is genuinely good at what it does in the browser, playing the result back, routing it, letting the user scrub and preview. If you've used AudioContext you know what I mean.
But the actual separation and transcription, the part that matters, that runs on the server. Either our own models or third party model APIs do the heavy compute, and the browser just sends the audio up, shows progress, and plays the result. So Web Audio in my case is the plumbing, not the brain.
That changes how you think about the product. You're not shipping compute, you're shipping a thin client with a good UI. The hard problems move to the backend: latency, cost per call, and keeping the models honest.
The stuff that bit me anyway
Mobile Safari is its own world. Things that are totally fine on desktop Chrome will just behave differently or refuse outright on iOS. Test there early.
Formats are inconsistent too. The browser can decode a lot but not everything, and of course the weird files are exactly the ones your users upload.
Large files will blow up upload time and memory if you're not careful, so you end up chunking and showing progress whether you like it or not. And there's a real tension between quality and how long the user waits. You can't fully win. You just pick which one your tool is for.
If you're thinking about building something like this
Start with the UX. Get the upload, the preview, and the result flow feeling instant even when the backend is slow. A spinner that lies is worse than an honest progress bar.
Keep the client thin. Push as much logic to the server as you reasonably can, and treat the browser as a view layer.
Test on the worst device and the worst connection you can find, not the laptop on your fast wifi.
And be straight about limits. A tool that admits what it's bad at earns more trust than one that promises everything.
If any of this was useful, ezaudio is at ezaudio.io. Free to try, runs in your browser.
Disclosure: this post was written with AI help and edited by a human. The technical points are general practice for browser-fronted, server-backed audio tools and lessons from building ezaudio, not a spec sheet.
Top comments (0)