Audio Joiner
runs in your browserJoin audio files into one in your browser: end to end, with silence between, or crossfaded. Reorder the clips, pick the curve, nothing uploaded.
Drop files here, or .
WAV, MP3, M4A, OGG, FLAC — or a video, and the sound is taken out of it. Nothing is uploaded.
Everything is brought to one sample rate and one channel count, because a joined file has only one of each.
about this tool
Drop several audio files, put them in the order you want, and get one file back — butted end to end, separated by silence, or crossfaded. Everything happens in the page; nothing is uploaded.
One file, one sample rate
A joined file has exactly one sample rate and one channel count, so every clip has to be brought to them. That sounds like a detail and is the main way this goes wrong: concatenate 44.1kHz and 48kHz samples without reconciling them and the mismatched clips play about a tenth too fast.
The browser does the reconciling as it decodes. decodeAudioData hands back
audio at the rate of the context that read it, whatever rate the file was
recorded at — which makes the joining safe and makes the choice of rate a real
decision. This uses 48kHz: a 44.1kHz recording resampled up gains no detail and
loses nothing you can hear, whereas decoding everything at 44.1kHz would cut
off everything above 22.05kHz in anything recorded at 48. Two honest costs:
the browser's resampler is not specified anywhere, so "loses nothing" is a
statement about the arithmetic rather than a guarantee about Chrome's filter;
and a set that was all 44.1kHz to begin with comes out about 9% larger than it
needed to be, having been resampled for nothing.
Channels are reconciled the same way, to the widest count in the set — and where each channel lands matters as much as how many there are. The placements come from the Web Audio API's own up-mixing table rather than from anything invented here, so a joined file is laid out the way the browser would lay it out itself: a mono clip goes to both sides of a stereo pair, but to the centre channel alone of a 5.1 set, and a stereo clip fills the front pair and leaves the rest silent.
That is worth saying because the obvious shortcut is wrong in a way nothing warns you about. Wrapping the channels round — channel 0 again for channel 2, channel 1 again for channel 3 — puts a full-bandwidth right channel into the LFE, which receivers deliberately boost, and doubles the fronts into the surrounds. No sample gets louder, so no peak meter and no waveform shows it; you find out on a surround system. The tool says in the plan how many channels the result will have, and says so when a clip is being widened.
The crossfade curve is not a preference
Fade one clip out along a straight line while fading the next in along a straight line, and the two amplitudes add to one all the way through. That is the obvious thing to do and it is wrong for almost every pair of clips, because unrelated sounds do not add as amplitudes — they add as powers. At the midpoint both clips sit at half amplitude, so the power is a quarter plus a quarter: half. That is −3dB, a clearly audible dip in the middle of the join.
The equal-power curve uses a quarter turn of cosine and sine, so the squares of the two gains add to one:
| Through the fade | Linear out / in | Equal-power out / in |
|---|---|---|
| start | 1.00 / 0.00 | 1.00 / 0.00 |
| middle | 0.50 / 0.50 — power 0.5 | 0.71 / 0.71 — power 1.0 |
| end | 0.00 / 1.00 | 0.00 / 1.00 |
Both are offered, because linear is not simply worse: if the two clips are the same recording — the same music overlapping itself — the amplitudes really do add, and then it is equal power that is wrong, giving a 3dB bump instead. The default is equal power because unrelated clips are the ordinary case for a tool that joins files.
A crossfade can never take more than half of the shorter of the two clips it joins. Half rather than all, which is the limit you would reach for first and which fails badly: at the full length, consecutive fades eat into each other, so a clip shorter than the fade is faded down from both ends at once and three clips land on the same samples. Twenty half-second effects with the default one-second fade came out as half a second of everything playing at once — and the only thing said about it was that a fade had been "shortened to fit". At half, fades can meet but never overlap, so the timeline can shrink and never collapse. When one is cut, the plan says what it was cut to.
When the result clips
Adding two signals can exceed full scale, and a crossfade adds them by definition. At the middle of an equal-power fade both clips are at about 71%, so two loud passages can sum past 100% and the result distorts.
The peak of the finished file is measured and reported rather than quietly reduced — turning the whole thing down to hide it would change audio you did not ask to have changed. Shorten the overlap, or bring the clips down before joining.
The loudest input sample is measured too, and the two are compared, because a tool that blames the join for everything is worse than useless: an already-mastered track sits at full scale on its own, and every end-to-end join of two of them would be reported as damage the tool had done. The notice only says the join caused it when the output is actually louder than anything that went in.
Formats, and one that is never there
WAV is written here directly, so it is always available. M4A, OGG and WebM go through an encoder the browser provides, and the list only offers what yours can actually write rather than failing after you commit. The audio trimmer covers the formats and the missing MP3 in more detail; the short version is that no browser will write one.
WAV avoids a second lossy generation, but it is not untouched: the join runs in 32-bit floating point and is written as 16-bit integer, undithered, so very quiet passages and the tails of fades are quantised. Anything that went over full scale is clamped at that point rather than reduced.
What it will not do
Everything is held as 32-bit samples while it works: every decoded clip, plus
the joined result beside it, plus the encoded bytes on top. So the ceiling is
counted in samples rather than minutes, because an hour of 5.1 is three times
the memory of an hour of stereo and a limit written in minutes lets the wide
one kill the tab at a duration the narrow one sails through. In round numbers
that is about 26 minutes of stereo, 52 of mono, or 8 of 5.1, and a hundred
files. Past it the tool refuses before decoding rather than failing somewhere
in the middle with a RangeError; join it in two halves and join the halves.
Joining always re-encodes: the clips have to become raw samples to be aligned and mixed. For material that was already lossy that is a second generation — usually inaudible on speech, more noticeable on music. WAV avoids adding a third.
To cut a single file rather than join several — trim, fade, normalise or convert it — the audio trimmer does that end, and shares this tool's encoders. To read what is inside a file before joining it, the media inspector reports the codec, the real sample rate and the channel count.
questions
- What happens if my files have different sample rates?
- They are all brought to 48kHz, because a joined file has exactly one sample rate and something has to give. The browser does the resampling as it decodes — a file comes back at the rate of the audio context that read it, whatever it was recorded at. 48kHz is chosen rather than 44.1kHz because resampling a 44.1kHz recording up adds no detail but discards none either, while going the other way would throw away everything above 22.05kHz in a 48kHz recording.
- Which crossfade curve should I use?
- Equal power, unless the two clips are the same recording. Fading one out and the next in along straight lines keeps the amplitudes adding to one, which sounds like a hole in the middle: for unrelated material it is the powers that add, so the join drops about 3dB exactly where you are listening. The equal-power curve uses a quarter turn of cosine and sine so the squares add to one instead, which is flat. Linear is right only for two copies of the same signal, where the amplitudes really do add.
- Why is my crossfade shorter than I asked for?
- Because it cannot be longer than the shorter of the two clips it joins — a three-second fade into a one-second clip would have to start before that clip does. It is shortened to fit and the panel says so rather than silently producing something else.
- What if some files are mono and others stereo?
- The result takes the widest channel count in the set, and the placements follow the Web Audio API’s own up-mixing table rather than a rule invented here. Mono into stereo goes to both sides rather than only the left, which is what padding with an empty channel gets you. Above stereo it matters more: mono into 5.1 goes to the centre channel alone, and a stereo clip fills the front pair and leaves the rest silent. Wrapping the channels round instead — the obvious shortcut — would put a full-range channel into the LFE, which receivers boost, and nothing in a waveform or a peak meter would show it.
- Are my files uploaded?
- No. They are decoded by your browser’s own audio engine, joined as raw samples in the page, and written back out by an encoder the browser provides. Nothing in this page sends them anywhere. That also means a long set costs no upload time, though it does cost memory — the ceiling is counted in samples rather than minutes, which works out at about 26 minutes of stereo, 52 of mono, or 8 of 5.1 — an hour of 5.1 is three times the memory of an hour of stereo, so a limit written in minutes would let the wide one kill the tab at a length the narrow one handles.
- Why is WAV the only format sometimes?
- WAV is written here directly, so it is always available. M4A, OGG and WebM need an encoder the browser provides, and not every browser provides one — the list only offers what yours can actually write, rather than failing after you press the button. No browser will write MP3, which is why it is not offered anywhere.
- What does the clipping warning mean?
- That the loudest moment in the result reaches full scale, which comes either from a crossfade adding two loud passages together or from a clip that was already mastered to full scale; the loudest input sample is measured too, so the notice only blames the join when the output is genuinely louder than anything that went into it — at the middle of an equal-power fade both clips are at about 71% and their sum can exceed 100%. Shorten the overlap or turn the clips down before joining. Nothing is silently reduced to hide it.
- Can it join the audio from a video?
- Usually. Drop an MP4 or WebM and the sound is decoded out of it, then treated like any other clip; MOV works in Chrome and Safari but not in Firefox, which does not support that container at all. The picture is discarded — this writes an audio file.
- Does joining re-encode the audio?
- Yes, and it has to: the clips are decoded to raw samples so they can be aligned, faded and mixed, then written back out once. Choosing WAV avoids a second lossy generation, though it is still written as undithered 16-bit, so the very quietest material is quantised. Choosing M4A or OGG encodes again, so material that was already lossy has been through two generations — usually inaudible for speech, more noticeable on music.