DEV Community: Khoa Nguyen

I replaced a $200/month audio processing server with 40 lines of browser JavaScript

Khoa Nguyen — Tue, 19 May 2026 14:37:07 +0000

Last year I was paying $200/month for an EC2 instance that did one thing: accept audio file uploads, run FFmpeg, and return the converted file. FLAC to MP3. WAV to OGG. Bitrate changes. Speed adjustments.

The server handled maybe 2,000 conversions per day. Most files were under 20 MB. The actual FFmpeg processing took 2-4 seconds per file. The upload and download took longer than the conversion itself.

I replaced the entire thing with client-side JavaScript. Here's how, and where the approach breaks down.

The Web Audio API is more capable than you think

Most developers know the Web Audio API as "the thing that plays sounds in games." It's actually a full audio processing pipeline with decode, transform, and encode capabilities.

The key insight: if the browser can play a format, it can decode it. And if it can decode it, you can re-encode it into any format the browser supports for encoding.

async function convertAudio(file, targetFormat = 'audio/mp3', bitrate = 192000) {
  const audioContext = new OfflineAudioContext(2, 1, 44100);
  const arrayBuffer = await file.arrayBuffer();
  const audioBuffer = await audioContext.decodeAudioData(arrayBuffer);

  // Now audioBuffer contains raw PCM samples
  // We can re-encode to any supported format
  const encoded = await encodeAudio(audioBuffer, targetFormat, bitrate);
  return new Blob([encoded], { type: targetFormat });
}

decodeAudioData handles FLAC, WAV, OGG, MP3, AAC, and WebM audio in all modern browsers. You get back raw PCM samples regardless of the input format. From there, encoding is a separate step.

Encoding with AudioEncoder (WebCodecs API)

The WebCodecs API landed in Chrome 94 and is now available in all Chromium-based browsers and Firefox. It gives you direct access to hardware-accelerated audio encoders.

async function encodeToMp3(audioBuffer, bitrate = 192000) {
  const numberOfChannels = audioBuffer.numberOfChannels;
  const sampleRate = audioBuffer.sampleRate;
  const frames = [];

  const encoder = new AudioEncoder({
    output: (chunk) => {
      const buffer = new ArrayBuffer(chunk.byteLength);
      chunk.copyTo(buffer);
      frames.push(buffer);
    },
    error: (e) => console.error('Encode error:', e),
  });

  encoder.configure({
    codec: 'mp3',
    numberOfChannels,
    sampleRate,
    bitrate,
  });

  // Feed PCM data in chunks
  const chunkSize = 1152; // MP3 frame size
  const totalSamples = audioBuffer.length;

  for (let offset = 0; offset < totalSamples; offset += chunkSize) {
    const frameCount = Math.min(chunkSize, totalSamples - offset);
    const data = new Float32Array(frameCount * numberOfChannels);

    for (let ch = 0; ch < numberOfChannels; ch++) {
      const channelData = audioBuffer.getChannelData(ch);
      for (let i = 0; i < frameCount; i++) {
        data[i * numberOfChannels + ch] = channelData[offset + i];
      }
    }

    const audioData = new AudioData({
      format: 'f32-planar',
      sampleRate,
      numberOfFrames: frameCount,
      numberOfChannels,
      timestamp: (offset / sampleRate) * 1_000_000,
      data,
    });

    encoder.encode(audioData);
    audioData.close();
  }

  await encoder.flush();
  encoder.close();

  return concatenateBuffers(frames);
}

This runs at near-native speed because it uses the platform's hardware encoder. On my M2 MacBook, a 5-minute FLAC file (50 MB) converts to 192kbps MP3 in about 1.8 seconds. The same file took 2.1 seconds on the EC2 instance, plus 8 seconds of upload time.

The fallback: FFmpeg.wasm for Safari

Safari's WebCodecs support for audio encoding is still incomplete as of early 2026. For Safari users, FFmpeg.wasm is the fallback:

async function convertWithFFmpeg(file, outputFormat = 'mp3', bitrate = '192k') {
  const { FFmpeg } = await import('@ffmpeg/ffmpeg');
  const { toBlobURL } = await import('@ffmpeg/util');

  const ffmpeg = new FFmpeg();
  await ffmpeg.load({
    coreURL: await toBlobURL('/ffmpeg-core.js', 'text/javascript'),
    wasmURL: await toBlobURL('/ffmpeg-core.wasm', 'application/wasm'),
  });

  const inputName = 'input' + getExtension(file.name);
  await ffmpeg.writeFile(inputName, new Uint8Array(await file.arrayBuffer()));

  await ffmpeg.exec([
    '-i', inputName,
    '-b:a', bitrate,
    '-map', 'a',
    `output.${outputFormat}`,
  ]);

  const data = await ffmpeg.readFile(`output.${outputFormat}`);
  return new Blob([data], { type: `audio/${outputFormat}` });
}

The initial FFmpeg.wasm load is ~30 MB (cached after first use). After that, conversions run at roughly 60-70% of native FFmpeg speed. Still faster than uploading to a server for files under 100 MB.

Audio compression without quality loss

Audio compression (reducing file size, not dynamic range) is mostly about bitrate selection. The perceptual quality curve for MP3 looks like this:

Bitrate	File size (5 min)	Perceptual quality
64 kbps	2.4 MB	Noticeable artifacts, AM radio quality
128 kbps	4.8 MB	Acceptable for speech, podcasts
192 kbps	7.2 MB	Transparent for most listeners
256 kbps	9.6 MB	Indistinguishable from source for 99% of people
320 kbps	12 MB	Placebo territory

For podcasts and voice content, 128 kbps mono is the sweet spot. For music, 192 kbps stereo is where most listeners cannot distinguish from the FLAC source in blind tests. Going above 256 kbps is measurably identical to the source on consumer equipment.

The practical implication: a 50 MB FLAC file becomes a 7 MB MP3 at 192 kbps with no audible difference. That's a 7x reduction with zero perceptual cost.

Speed change without pitch shift

Changing audio playback speed while preserving pitch is a time-stretching problem. The Web Audio API has a built-in solution:

function changeSpeed(audioBuffer, speedFactor) {
  const newLength = Math.round(audioBuffer.length / speedFactor);
  const offlineCtx = new OfflineAudioContext(
    audioBuffer.numberOfChannels,
    newLength,
    audioBuffer.sampleRate
  );

  const source = offlineCtx.createBufferSource();
  source.buffer = audioBuffer;
  source.playbackRate.value = speedFactor;
  source.connect(offlineCtx.destination);
  source.start();

  return offlineCtx.startRendering();
}

playbackRate with OfflineAudioContext renders the speed-adjusted audio to a new buffer without pitch artifacts. The browser's internal resampler handles the time-stretching. Quality is comparable to SoX or Audacity's default algorithm.

This is how I built the audio speed changer on my site. Users upload a file, pick a speed (0.5x to 3x), and download the result. The entire operation runs in the browser in under 2 seconds for a typical podcast episode.

Where this breaks down

Files over 500 MB. The Web Audio API loads the entire decoded PCM into memory. A 60-minute FLAC at 44.1kHz stereo is ~600 MB of raw PCM. On mobile devices with 3-4 GB of browser memory, this causes crashes. For large files, you need chunked processing with AudioDecoder (WebCodecs) instead of decodeAudioData.

Exotic formats. The browser can decode what it can play. Formats like APE, WV (WavPack), and DSD are not supported. For these, FFmpeg.wasm is the only browser-side option.

Safari audio encoding. As mentioned, Safari's AudioEncoder support is incomplete. You need the FFmpeg.wasm fallback or accept that ~15% of users get a slower path.

Batch processing. Converting 50 files sequentially in a browser tab is technically possible but UX-hostile. Users expect to close the tab. For batch workloads, a server (or at minimum a service worker with Background Fetch) is still the right architecture.

The economics

My old setup:

t3.medium EC2: $30/month
EBS storage for temp files: $10/month
Data transfer (uploads + downloads): $80-150/month
CloudFront for delivery: $20/month
Total: ~$200/month for 2,000 conversions/day

My current setup:

Static hosting on Cloudflare Pages: $0
Total: $0/month for unlimited conversions

The conversion moved from my bill to the user's CPU. But the user's experience is better because there's no upload wait, no queue, and no "your file is being processed" spinner. The 8-second upload that used to precede every conversion is gone.

What I'd build differently today

Start with WebCodecs, fall back to FFmpeg.wasm. I did it the other way around and had to refactor when WebCodecs matured.
Use AudioDecoder for large files from day one. Streaming decode avoids the memory cliff that decodeAudioData hits at ~500 MB.
Show a progress bar based on samples processed. The Web Audio API doesn't give you progress events, but you can calculate it from the chunk offset in the encoding loop.
Test on Android Chrome early. Mobile Chromium has lower memory limits and some WebCodecs codecs are software-only (no hardware acceleration). Performance is 2-3x slower than desktop.

The browser audio stack in 2026 is production-ready for the vast majority of consumer audio processing tasks. If you're still routing audio files through a server for format conversion, compression, or speed adjustment, you're paying for infrastructure that delivers a worse user experience than the zero-infrastructure alternative.

I built all of this into a set of free browser-based audio tools — FLAC to MP3, audio compression, speed change, trimming, noise removal. No upload, no signup, no watermark. The patterns above are what's running in production.

Happy to answer questions about specific codec support or edge cases in the comments.

I stopped paying for 6 different online tools. Here's the one free site I use now.

Khoa Nguyen — Tue, 12 May 2026 09:23:38 +0000

Running a small business means juggling a dozen subscriptions you barely use. $10/mo for a PDF editor. $8/mo for an image resizer. $12/mo for a video trimmer. It adds up fast — and most of us only use 10% of the features.

A few months ago I found brevtool.com and it replaced almost all of them. It's a free website with 86 browser-based tools — and I mean actually free. No "free trial." No credit card. No account needed.

Here's what I use it for every week:

📄 PDF tools — Merge contracts, split invoices, compress PDFs before emailing clients. I used to pay for SmallPDF.
dev
🖼️ Image tools — Resize product photos for social media, compress images for my website (page speed matters for SEO), convert between formats. Replaced my Canva Pro image exports and TinyPNG subscription.

🎬 Video editor — Trim and cut clips for Instagram Reels and TikTok. Basic editing without installing anything. No watermark on exports.

🔗 QR code generator — I print QR codes on business cards, flyers, and packaging. Used to use a paid QR service.

🧮 Business calculators — Loan calculator, percentage calculator, unit converters. Small things, but I use them constantly.

🔧 Dev/text tools — JSON formatter, word counter, case converter, Base64 encoder. If you manage a website yourself, these save time.

The thing that sold me: everything runs inside your browser. Your files never get uploaded to anyone's server. For someone who handles client contracts and sensitive business documents, that matters. I don't want my NDAs sitting on some random company's cloud.

It's not perfect — the video editor is basic compared to CapCut or Premiere. But for quick social media clips and everyday business tasks? It handles 90% of what I need at 0% of the cost.

If you're bootstrapping or just tired of death-by-subscription, bookmark this one: brevtool.com

What free tools have saved you the most money in your business? I'm always looking to trim more subscriptions. 👇

I shipped 122 web tools without a backend

Khoa Nguyen — Thu, 07 May 2026 01:47:08 +0000

A year ago I deleted my server bill.

Not because I was broke. Because I realized that for the kind of tools I was building — file converters, formatters, calculators, generators — the server was the worst part of the architecture. It cost money, it leaked user data, it added latency, and it was the single biggest reason competitors in the space charge $9.99/month for a feature that could run in 3KB of JavaScript.

So I deleted it. Then I built 122 browser-based tools on top of that decision. Here's what actually worked, what didn't, and why I think every dev should be re-evaluating the "we'll just spin up a Lambda" reflex.

The thesis

Every file you upload to a SaaS converter is:

Sent over the network (slow)
Processed on someone's server (expensive)
Stored, even briefly (privacy risk)
Returned to you (slow again)

For ~80% of common tools, none of those steps need to happen. The browser in 2026 can do it. Not "kind of," not "with limitations" — actually do it, often faster than the round-trip to a server.

The mental shift: stop thinking of the browser as a thin client.

What worked surprisingly well

WebAssembly for "real" file processing

Every PDF tool I shipped runs in the browser via WASM. PDF compression, merging, splitting, conversion — all of it. The wins:

// Pseudocode for the pattern that replaced our backend
const file = await input.files[0].arrayBuffer();
const result = await wasmModule.compress(file, { quality: 0.7 });
download(result, 'compressed.pdf');

That's it. No upload. No queue. No "your file is being processed." A 50MB PDF compresses in ~2 seconds on a mid-range laptop, faster than uploading it to a server would take.

The same pattern works for image compression, video trimming (with FFmpeg.wasm), audio conversion, and even some surprising things like ZIP creation and EPUB generation.

If you're still routing files through a server for compression or format conversion, you are paying real money to deliver a worse experience.

Pure-JS for the boring 80%

Most "tools" don't need WASM. Most don't even need a framework. A JSON formatter, a regex tester, a character counter, a text case converter — these are 50–200 lines of plain JavaScript. The tool is the value. The framework is overhead.

I tried Vue. I tried plain HTML. I ended up on Next.js for SEO reasons (more on that below), but each tool's actual logic is a single function. Don't over-engineer.

Web Workers for anything >200ms

The single biggest UX upgrade across the whole site came from one rule: if a computation takes more than 200ms, it goes in a worker. Otherwise the page freezes during processing and people think the tool is broken.

const worker = new Worker(new URL('./hash.worker.js', import.meta.url));
worker.postMessage({ file, algorithm: 'sha256' });
worker.onmessage = (e) => updateUI(e.data);

Hashing a 1GB file on the main thread → frozen tab → user closes it. Hashing the same file in a worker with progress events → smooth experience, user trusts the tool. Same code, ten times the perceived quality.

What didn't work

"Just ship 122 tools and the SEO will come"

This was wrong. I shipped them, they got indexed (264 pages eventually), and Google parked the entire site at average position 72 for months. Indexed ≠ ranking.

The fix wasn't more tools. It was fewer, better-linked, better-content tool pages. Each tool now has:

A unique H1 with the actual keyword
A "How it works" section explaining the in-browser processing
An FAQ targeting common variations of the search query
3–5 internal links to related tools

Average position is finally moving. Lesson: SEO for tool sites is content + authority, not tool count.

Building everything from scratch

I tried to write a custom WASM PDF library. It took two weeks. PDF-lib already existed and was better. I wrote a video trimmer in raw WebCodecs API. FFmpeg.wasm did it in a tenth of the code.

For browser tools, the ecosystem in 2026 is mature. Use it. The "I built it from scratch" badge is worth less than shipping the tool a month earlier.

Mobile-first as an afterthought

50% of traffic to free-tool sites is mobile. Half my early tools assumed a 1280px screen. The fix wasn't responsive CSS — it was rethinking the workflow. On mobile, a "drag and drop your file" interface is useless. People tap, they don't drag. They want one button that opens the file picker.

If you're building utilities, design the mobile flow first.

The architecture that emerged

After 122 tools, the pattern stabilized:

┌─────────────────────────────┐
│  Static Next.js page (SSG)  │  ← SEO, fast first paint
├─────────────────────────────┤
│  Lazy-loaded tool component │  ← only loads when user interacts
├─────────────────────────────┤
│  Web Worker (when needed)   │  ← keeps UI responsive
├─────────────────────────────┤
│  WASM module (when needed)  │  ← for "real" processing
└─────────────────────────────┘

No API. No database. No queue. No auth. No Stripe. The whole site is static files served from a CDN. My infra cost is the domain and a Cloudflare account.

This is not appropriate for every product. It is appropriate for far more products than developers currently use it for.

When to stop being clever and just ship a backend

For honesty's sake, the in-browser approach breaks down for:

Files >2GB — browser memory limits get awkward, even with streaming
Long-running batch jobs — users won't keep a tab open for 20 minutes
Anything requiring a private API key — you can't ship secrets to the client
Heavy ML models — possible with WebGPU/ONNX but the UX still trails server inference

For everything else: try the browser-first version. You will be surprised how often it works.

What I'd tell past-me

Pick the boring tools first. A JSON to CSV converter ranks faster than a novel idea, because the search demand already exists.
WASM is not scary. Pick a library, copy the README, ship.
Don't build your own UI library. Use what exists. Spend the saved time on actual tools.
Static + client-side is a competitive advantage when your competitors are paying for servers.
Privacy isn't a feature you bolt on. It's an architecture decision you make on day one.

The web platform is genuinely capable now. A lot of "we need a backend for this" is muscle memory from 2015. It's worth questioning.

If you want to poke at any of the 122 tools, they're all here — none of them upload your files, all of them are free, and the source patterns above are the same ones running in production. Ask me anything in the comments.