The result you should expect when you join audio files is a single, freshly encoded PCM16 WAV file whose decoded samples appear in the same channel order and list order you confirm on screen. The output begins with a 44-byte RIFF/WAVE header and continues with interleaved, little-endian, signed 16-bit PCM samples drawn from one shared AudioContext. Because every source in a selection is decoded through that same context, the result uses the context's working sample rate, which may differ from the rates stored in each original file, and that working rate is what the header reports. None of the source codec, bitrate, encoder settings, ID3 tags, album art, chapters, cue points, loop points, loudness fields, or other container metadata carry into the merged file; the result is a new static PCM representation of what the browser actually decoded. Float samples are clipped to the -1 through 1 range, with negative full scale written as -32768, positive full scale written as 32767, and any non-finite values rendered as digital silence. The last sample frame of one track is followed immediately by the first sample frame of the next track in each channel array, with no inserted silence, overlap, crossfade, normalization, transition, or automatic trimming between them.
That single sentence is the core of the expectation: the merged file is brand-new, byte for byte, but its samples match exactly what the Web Audio decoder produced in the order you asked for. Everything that follows is a breakdown of how that core shows up in the file on disk, in the bytes the encoder writes, in the properties you can measure, and in the limits that decide whether the merge completes at all.
What the Output WAV Actually Contains
Every merged file is a new encoding, not a copy that preserves anything from the source containers. The header is written by a shared encoder that always follows the same RIFF/WAVE layout: the RIFF size, the WAVE and fmt identifiers, a PCM format tag, the channel count, the decoded sample rate, the byte rate, the block alignment, the 16-bit depth, the data identifier, and the exact data byte length. After those 44 bytes, channels are interleaved in frame order, so for a stereo file the layout repeats left sample, right sample, left sample, right sample for every time slice. Audio samples themselves are stored as 16-bit signed little-endian integers, which is the format every common audio player recognizes as PCM16 WAV. Because the header reflects whatever the AudioContext produced, the sample rate shown next to the merged file may be the same as your sources or a single rate that the context normalized them to.
For an overview of how decoded audio is represented in memory before it gets interleaved, the MDN AudioBuffer reference documents the float sample arrays that the joiner concatenates per channel. The merge plan copies each decoded channel into one continuous Float32 array at tested cumulative frame offsets, then clips and interleaves those floats into the on-disk PCM samples you actually hear.
Sample Rate and Channel Behavior in the Result
Two properties of the result depend on the browser rather than on the files you selected. First, the working sample rate of the AudioContext may resample sources to one rate, so the rate reported for the merged file can differ from the rates stored in the original files. Web Audio does not preserve independent source sample rates; one rate is used across the entire merged output, and that is what gets written into the fmt chunk of the WAV header. Second, the channel count of the result is exactly the channel count your files decoded to, provided every file in the selection agrees. A mono and stereo mixture is rejected with a specific message rather than being silently duplicated, dropped, averaged, or remapped. Matching channels are kept in their decoded order and concatenated independently before WAV interleaving, which is how track order and channel identity survive the join rather than being collapsed by an automatic downmix.
For multi-channel work the joiner accepts up to eight channels per selection and rejects anything above 192 kHz, so high-rate or multichannel selections can reach the sample budget before they hit the duration cap. The selection is rejected rather than being silently trimmed or downmixed to fit.
What the Joiner Drops, Hides, or Silently Alters
The merged file is a new PCM representation, and several properties of your source files are intentionally not preserved. The output does not carry forward the original codec, the original bitrate, the encoder settings used to make each source, ID3 tags, album art, chapters, cue points, loop points, loudness fields, timestamps, or any other container metadata. It also adds nothing on top: there is no inserted silence, overlap, crossfade, normalization, transition, or automatic trimming between the files you selected. If your task depends on any of those behaviors, the no-gaps-or-fades behavior is documented separately so you can predict exactly what each merged second will sound like.
Three adjustments are applied, all to float samples before they are written as 16-bit PCM. Clipping forces every value into the -1 to 1 range, so a track that decodes louder than full scale will not wrap or distort in the WAV; the loudest legal samples are written as -32768 and 32767. Non-finite floating-point values, which can appear if a damaged source produced NaN or Infinity during decode, are written as silence rather than as garbage. These rules apply uniformly across every channel of the merged file, so the channel-concatenation step and the PCM write step produce the same bytes when given the same decoded inputs.
Size and Time Budgets You Should Plan Around
The merged WAV is often larger on disk than the files you put in. PCM16 WAV is uncompressed audio: each second of stereo audio at 44.1 kHz is roughly 176 KB before container overhead, while a similar MP3 or AAC source might be only a small fraction of that. If you are merging a ten-minute interview from MP3 sources, the merged WAV can easily land in the 100 MB range. The joiner enforces explicit budgets so you find out about size problems before you commit:
| Budget | Limit |
|---|---|
| Files per selection | 2 to 10 |
| Per-file encoded size | 25 MiB (26,214,400 bytes) |
| Total selection size | 100 MiB (104,857,600 bytes) |
| Total decoded duration | 30 minutes |
| Channel count | up to 8 |
| Sample rate | up to 192 kHz |
| Channel-sample budget | 30 million samples across all channels |
Nothing is shortened, downmixed, downsampled, or omitted to fit a budget. A selection that exceeds any of these limits is rejected with a specific message, which is why the limits are surfaced on the screen before you click Join rather than being enforced silently during decoding. For background on how decoding produces the float arrays the encoder turns into PCM samples, the MDN decodeAudioData reference documents the function the joiner calls once per file in the selection.
How to Produce That Result Step by Step
The merged WAV you are planning for is generated through a fixed sequence. The picker recognizes common MP3, WAV, M4A, AAC, Ogg, WebM, and FLAC names and MIME types, although a recognized extension does not guarantee that every codec variant can be decoded by your specific browser.
- Open the tool and pick the files. Use Audio Joiner and select 2 to 10 files at once. The picker shows the current per-file and total byte limits so you can drop in files without re-checking sizes by hand.
- Wait for browser decoding. Each file is decoded through a single AudioContext. If anything is damaged, encrypted, incomplete, mislabeled, or unsupported by your browser, the joiner surfaces a clear error instead of silently producing a broken WAV.
- Preview each decoded track. Use the temporary local object URLs to listen to each file as the browser decoded it. This is the moment to catch a wrong file, a wrong channel count, or a rate you did not expect before joining.
- Set the order with Move up and Move down. Reordering changes the decoded-buffer array and the visible list together, and clears any older WAV so a stale result cannot claim a previous order.
- Join in this order, preview the WAV, then download. The encoder writes a new RIFF/WAVE file with interleaved little-endian PCM samples at the AudioContext's working rate. Check the merged file before you close anything, since your original sources are still on disk and have not been modified.
Confirm the Result Matches Your Expectations
Treat the merged WAV as a new file whose bytes you have not inspected yet. Confirm the duration, the order of tracks, the joins between tracks, the channel playback (headphones versus speakers versus summing to mono on a phone speaker), and the file size before deleting any original. Because nothing about the merge alters your source files on disk, you can repeat the merge with a different ordering or a trimmed selection until the result lines up with what you wanted. If your task would have benefited from a crossfade, loudness match, channel conversion, compressed output, metadata preservation, or sample-level repair, the joiner is intentionally the wrong tool and an audio editor or a different utility is the right next step.