Sample MP3 Generator
Generate a genuine MP3 file in seconds — seven audio content types, real client-side encoding, real ID3v2 and ID3v1 tags, and an exact target file size. No renamed WAV files. Runs entirely in your browser.
Quick Tips for the Right Test File
Features
The First Format Here That Sounds Like Something
Every generator in this set up to this point has produced something you look at or parse. This one produces something you listen to, and that difference reaches all the way down into how the file gets built. There's no canvas, no XML, no ZIP-packaged object model — instead, raw PCM samples get computed directly, sample by sample, then run through a genuine port of the LAME encoder to become real MPEG audio frames. It's the same fundamental approach this library used for Sample GIF's hand-built LZW compressor: when no simpler browser API exists for a real encoding job, the actual encoding gets done for real, not faked.
Lossy compression is the other thread connecting this generator to the rest of the library. Sample WebP Image and Sample JPG Image both trade quality for file size through an adjustable dial, and MP3 works the same way — Bitrate here is the direct audio equivalent of a JPEG quality slider, a real, continuous trade-off between fidelity and size rather than a fixed setting with no real effect.
Content still matters independently of that dial, the same way it does for the image generators. A Pure Tone at 128kbps and White Noise at 128kbps rarely end up the same actual size once encoded — tonal, low-entropy content compresses more efficiently than genuinely random samples do, since the encoder has real redundancy to exploit in one case and essentially none in the other. That difference is exactly why White Noise exists here as its own deliberate content type rather than a variation on Pure Tone.
Padding That's Actually Meant to Be There
Every other format in this library pads toward an exact size by repurposing something the format never designed for padding specifically — an XML comment, an unreferenced ZIP entry, a private chunk type. ID3v2.3 is different: its own specification explicitly describes reserving extra tag space beyond the actual metadata frames, filled with zero bytes, precisely so a media player or tag editor can update a file's Title or Artist later without rewriting the entire audio stream around it. Using that space here isn't a workaround at all — it's the format's own padding mechanism, used exactly as documented.
That also means growing to a large target is genuinely free of the caveats other formats carry: no even-byte requirement, no minimum chunk footprint, just zero bytes in a space the spec built for exactly this.
Two Tagging Systems, One File
ID3v2 and ID3v1 aren't different versions of the same idea so much as two entirely different eras of MP3 metadata coexisting in the same ecosystem. ID3v2.3 sits at the very front of the file, supports genuinely arbitrary text length, and encodes it in real UTF-16 so accented names and non-Latin scripts survive intact. ID3v1 sits at the very end, dates back to a time before Unicode was a given, and crams every field into a fixed 30 or fewer bytes of raw single-byte characters — which is exactly why non-Latin text in that trailing tag may not display correctly in a player that only understands the original ID3v1 specification. That's a genuine, honest limitation of the older format itself, not an oversight in how this generator writes it.
Turning Legacy ID3v1 Tag on adds that second block for exactly this reason: plenty of real MP3 files in the wild still carry both, specifically because older hardware and software occasionally only ever look at the one at the end.
Genre in the ID3v1 block is a small, honest quirk worth mentioning on its own. The original specification defines genres as numeric codes pointing into a fixed list rather than free text, so this generator writes 12 — "Other" — as a safe, always-valid choice rather than guessing at a code that might not mean what it looks like it means.
Who Actually Needs a Real Test MP3
Backend developers validating an upload pipeline's MIME-type and duration handling need a genuinely encoded MP3 with real, parseable frame headers, since a renamed WAV fails a real content-sniffing check immediately. Telephony and IVR developers testing DTMF detection need DTMF Tones specifically — the real frequency pairs, not a stand-in beep. Audio-pipeline engineers testing transcoding or streaming infrastructure benefit from White Noise's worst-case compressibility and Stereo Test's independent channels, neither of which a single fixed tone can substitute for.
QA teams covering an audio upload or playback feature end-to-end benefit from working through several content types deliberately rather than one convenient tone repeatedly — a player that handles Pure Tone correctly can still stumble on Silence's near-zero amplitude, or on Click Track's precisely timed transients, each exercising a genuinely different part of a decoder or waveform renderer.
Click Track: The Simplest Signal With the Clearest Use
A regularly spaced transient every second sounds almost too simple to deserve its own content type, but that simplicity is exactly the point — it's far easier to verify precise timing against a stopwatch or a DAW's own timeline from a sharp, discrete click than from a continuous tone, which makes it the fastest way to confirm a decoder or streaming pipeline isn't silently dropping or duplicating samples across a longer file.
Where This Tool Isn't the Right Pick
This generator produces synthetic test signals, not music or speech — if a test specifically needs realistic program content rather than a reference tone or noise floor, a real recording is the right source, not a generated one. It also only produces MP3 specifically; a test that needs a different container or a lossless format entirely calls for a different tool than a reference-tone generator.