How to Edit Audio Online: Convert, Trim, Boost, and Merge

Audio work has a reputation for requiring expensive software and a trained ear. Most of it does not. The overwhelming majority of real audio tasks are mundane: an interview recording that is too quiet to hear, a voice memo in a format the transcription service rejects, three separate takes that need joining, a two hour meeting recording where only eight minutes matter, a video whose soundtrack you need on its own. None of these require a studio. All of them can be done in a browser tab in a couple of minutes, once you know which lever to pull.

What makes audio feel harder than it is comes down to a handful of numbers that are rarely explained. Bitrate, sample rate, bit depth, channel count, and loudness sound technical and interrelated, and most tools present them as a wall of dropdown menus with no guidance. In reality each one answers a simple question, and once you know what the question is, choosing a value takes seconds.

This guide walks through the formats you will meet and what each is for, the settings that determine quality and size, the four editing operations that cover almost every practical need, why so many recordings are too quiet and how to fix that properly, how to pull audio out of video files without losing anything, and a complete workflow for turning a raw recording into something publishable.

Audio Formats: MP3, WAV, AAC, FLAC, and OGG

Audio formats divide into three groups, and knowing which group a format belongs to answers most questions about it immediately.

Uncompressed: WAV and AIFF

These store the raw digital samples exactly as captured, with no compression at all. Nothing is thrown away, nothing is approximated, and every edit starts from the true recording. The cost is size: stereo audio at 44100 Hz and 16 bits per sample runs about 10 MB per minute, which means a one hour interview is roughly 600 MB.

WAV is the Windows standard and AIFF is the Apple equivalent. Both are universally supported by editing software and both are the correct choice while you are still working on a file. Neither is appropriate for distribution, because you would be asking listeners to download ten times more data than they need.

Lossless compressed: FLAC and ALAC

These compress audio the way a ZIP file compresses a document. The original data is reconstructed perfectly on playback, so there is no quality loss whatsoever, but the file is typically 40 to 60 percent smaller than the equivalent WAV.

FLAC is open and widely supported on desktop and Android. ALAC is Apple's equivalent and integrates with their ecosystem. Both are excellent for archiving master recordings, since you keep perfect fidelity at roughly half the storage cost. Browser support is patchy, and neither is a sensible choice for something you email to a colleague.

Lossy compressed: MP3, AAC, and OGG

These achieve their much smaller sizes by permanently discarding audio information, guided by models of what human hearing actually detects. They exploit effects such as masking, where a loud sound makes a simultaneous quieter sound at a nearby frequency inaudible, so the quiet one can be removed entirely without anyone noticing.

• MP3 is the format everything plays. It is nearly thirty years old and less efficient than newer options at the same bitrate, but its compatibility is unmatched. At 192 kbps and above the difference from the source is inaudible to most listeners in most conditions.
• AAC is the successor, offering noticeably better quality at the same bitrate, particularly below 128 kbps. It is the standard audio format inside MP4 video, the default for Apple devices, and what most streaming services deliver.
• OGG Vorbis is open and royalty free, with quality between MP3 and AAC. It is common in games, on some open platforms, and in older web applications.
• Opus is the modern royalty free codec and is genuinely outstanding, especially for speech at low bitrates where it can sound clean at 32 kbps. It is what most voice and video calling uses. Support outside browsers and modern devices is still limited.

The one rule that matters most

Convert from lossless to lossy exactly once, at the end. Every additional lossy encode compounds the damage, because the second encoder has no idea which artifacts were introduced by the first and treats them as real audio worth preserving. Take an MP3, convert it to another MP3, and you have thrown away detail twice for no benefit.

A useful corollary: converting MP3 to WAV does not improve anything. It stores the already damaged audio in a bigger container. The only reason to do it is that a specific piece of software demands WAV input.

When you do need a different format, a browser based audio converter handles the common pairs quickly, and because it processes on your own machine, interview recordings and client work never leave your device.

Bitrate, Sample Rate, and Channels Explained

Four settings determine what an audio file sounds like and how big it is. Each answers a different question.

Bitrate: how much data per second

Bitrate applies to lossy formats and controls how much data is spent describing each second of audio, measured in kilobits per second. It is the single biggest quality lever you have, and it maps directly to file size: bitrate multiplied by duration, divided by 8, gives megabytes.

Variable bitrate, usually written VBR, is worth choosing when offered. It spends more data on complex passages and less on simple ones, producing a smaller file at the same perceived quality than a constant bitrate encode. The only reason to prefer constant bitrate is compatibility with older hardware players or streaming systems that need a predictable rate.

Sample rate: how often the sound is measured

Digital audio works by measuring the sound wave many thousands of times per second. The sample rate is how many measurements per second, in hertz. It determines the highest frequency the file can represent, which is exactly half the sample rate.

• 44100 Hz is the CD standard and captures up to 22050 Hz, comfortably above the roughly 20000 Hz ceiling of human hearing. This is the default for music.
• 48000 Hz is the film, television, and broadcast standard. Any audio that came from video will be at this rate, and keeping it there avoids an unnecessary conversion.
• 96000 Hz and higher gives extra headroom during recording and heavy processing, but delivers no audible improvement in a finished file while doubling the size.
• 22050 Hz and 16000 Hz are speech rates. They sound noticeably dull on music but are perfectly serviceable for voice and dramatically smaller.

Two practical warnings. Resampling is a lossy mathematical operation, so converting 48000 to 44100 and back again degrades the file both times. Pick a rate at the start and keep it. And a mismatched sample rate is the classic cause of audio that plays too fast or too slow with a shifted pitch, which happens when a file is tagged one rate and played at another.

Bit depth: how precisely each measurement is stored

Bit depth applies to uncompressed and lossless formats and determines the dynamic range, meaning the distance between the quietest and loudest sound that can be represented. 16 bit gives about 96 decibels of range, which is the CD standard and is entirely sufficient for finished audio. 24 bit gives about 144 decibels and is the sensible choice while recording, because the extra headroom means a passage that turns out louder than expected does not clip.

Record in 24 bit, deliver in 16 bit. Lossy formats do not expose bit depth at all, since the concept does not apply to how they store data.

Channels: mono, stereo, and why mono is underrated

Mono is a single channel of audio. Stereo is two, carrying separate left and right information to create a sense of space. Surround formats carry five or more.

The point people miss is that a single voice recorded on a single microphone contains no stereo information at all. Encoding it as stereo stores two nearly identical channels and doubles the data for zero benefit. Converting speech recordings to mono halves the file size with no audible change whatsoever. For a two hour interview at 128 kbps, that is a saving of over 50 MB for nothing.

Keep stereo for music, for anything with deliberate spatial placement, and for recordings made with two microphones in different positions. Use mono for interviews, lectures, voice notes, narration, and single microphone podcasts.

Trimming and Merging Audio Files

These two operations account for the majority of practical audio editing, and neither requires any real skill. What they require is knowing where to cut and how to join without an audible seam.

Trimming: removing what nobody needs to hear

Almost every raw recording has removable material. Meeting recordings start with several minutes of people joining and small talk. Interviews open with microphone checks. Voice memos begin with the sound of a phone being positioned. Lecture recordings run on after the last question. Cutting the head and tail typically removes 10 to 25 percent of a file with no downside at all.

Two things make a trim sound professional rather than abrupt. First, cut at a natural silence rather than mid word, and leave a short breath of room tone rather than slicing to the exact syllable, which sounds unnaturally tight. Second, apply a very short fade, in the region of 10 to 50 milliseconds, at each cut point. A hard cut in the middle of a waveform produces an instantaneous jump in the signal that the ear hears as a click. The fade removes it and is far too short to be perceived as a fade.

For speech, a slightly longer fade of 100 to 200 milliseconds at the very start and end of the whole file sounds more polished than an abrupt beginning. Dropping the file into a browser based audio trimmer and cutting to the section that matters is often the entire job, particularly when someone has sent you a ninety minute recording containing four useful minutes.

Merging: joining files without a jump

Merging joins multiple files end to end. It sounds trivial and usually is, but three details determine whether the result sounds seamless or obviously stitched together.

• Match the technical settings first. All files must share a sample rate, channel count, and format. A good merging tool converts automatically, but be aware of what it converts to. Joining a 44100 Hz file to a 48000 Hz file means one of them is resampled.
• Normalize levels before merging, not after. If one recording is quieter than the next, normalizing the merged file cannot fix it, because normalization scales everything by the same amount. Level each source file individually first, then join them.
• Quality settles at the weakest link. Joining a 320 kbps segment to a 64 kbps segment produces a file where the difference is plainly audible. Match sources where you can.

Common merging jobs include joining several takes of a narration, assembling an intro, body, and outro for a podcast episode, combining voice notes recorded over several days, and stitching a recording that was split by a device size limit. For the last case, check that no audio was lost at the split point, since some recorders drop a fraction of a second between files.

If the transition still sounds abrupt, a short crossfade of 200 to 500 milliseconds blends the end of one file into the start of the next and hides the seam entirely, particularly when the room tone differs between recordings.

Loudness, Normalization, and Volume Boosting

The most common complaint about any recording is that it is too quiet. The fix depends on why it is quiet, and applying the wrong one makes things worse.

Why recordings come out quiet

Digital audio has an absolute ceiling. Exceed it and the waveform is clipped flat, producing harsh distortion that cannot be repaired. Because that damage is permanent, recording devices and their automatic level controls stay conservatively far below the ceiling. Phones, laptop microphones, and consumer recorders routinely capture peaks at 40 to 60 percent of the available range, which sounds quiet but is entirely safe and entirely fixable.

The important consequence is that a quiet recording is usually not a damaged recording. The information is all there, sitting at a low level. Raising it is a straightforward operation with no quality cost beyond making the noise floor more audible.

Normalization: the right first step

Normalization finds the loudest point in the file and scales the entire file so that point sits just below the maximum, typically at minus one decibel to leave a little safety margin. Everything gets louder by the same amount, so the relationship between loud and quiet passages is completely preserved.

This is called peak normalization and it is the correct first move for almost any quiet file. It is mathematically clean, it introduces no distortion, and it usually solves the problem outright.

Its limitation is that it responds to a single loudest sample. One accidental cough, door slam, or microphone bump sets the ceiling, and the rest of the file stays quiet because that one spike used up all the headroom. When normalization does not seem to help, this is almost always why. Trim or reduce the offending spike first, then normalize again.

Loudness normalization: what platforms actually measure

Peak normalization measures the highest instantaneous value. Perceived loudness is a different thing, closer to average energy over time. A file can peak at maximum and still sound quiet if most of it sits far below.

The broadcast and streaming industry uses LUFS, Loudness Units relative to Full Scale, which models perceived loudness across the whole programme. Target levels are worth knowing if you publish audio: podcasts generally aim for around minus 16 LUFS for stereo and minus 19 LUFS for mono, Spotify and YouTube normalize toward roughly minus 14 LUFS, and broadcast television typically targets minus 23 LUFS.

Since streaming platforms adjust everything to their own target anyway, mastering a podcast far louder than the standard gains nothing and simply means the platform turns it down, leaving you with the compression artifacts you added for no reason.

Compression: reducing the gap before raising the level

When a recording has a very wide range, for instance an interview where one person leans in and the other sits back, normalization alone is not enough. Raising the level far enough to hear the quiet speaker would push the loud one past the ceiling.

Dynamic range compression solves this by reducing the level of the loudest parts, which shrinks the gap between loud and quiet, and then raising the whole file. The result is a more consistent listening level. Applied gently it makes speech much easier to follow, especially in a car or on public transport. Applied heavily it sounds airless and fatiguing, and it pulls up background noise along with everything else.

For speech, a modest ratio around 3:1 with a threshold set so that only the loudest phrases are affected is a good starting point, followed by normalization to bring the whole thing up.

Boosting a file that is still too quiet

Some recordings are simply so far below the ceiling that normalization to minus one decibel is not enough, or the file needs to be louder than its own peak allows. Amplification multiplies the signal directly, and when it pushes past the maximum a limiter catches the excess rather than letting it clip.

Two things to keep in mind. Raising the signal raises the noise with it, so hiss, air conditioning hum, and room tone become more prominent. And beyond a certain point limiting becomes audible as a squashed, breathing quality. If a file needs more than about 12 decibels of boost, address the noise floor first or accept that the source has limits.

Extracting Audio From Video Files

A video file already contains a fully formed audio stream sitting alongside the picture. Extracting it means separating that stream out, not recreating it, which is why the results are so much better than the alternative of playing the video and recording the output.

When extraction is completely lossless

If the audio inside the video is already in the format you want, it can be copied out byte for byte without being decoded and re-encoded. An MP4 file almost always contains AAC audio, so extracting to an .m4a or .aac file is a pure copy that finishes in seconds and is mathematically identical to the source.

Converting to MP3 requires a re-encode, since AAC and MP3 are different codecs. That costs one generation of quality. It is usually worth it for compatibility, but if the destination accepts AAC, copying it directly is strictly better.

Why you should never record the playback

Playing a video and capturing the sound with a screen recorder or a loopback device adds a decode step, a playback step, a capture step, and another encode step. It picks up any system sounds that happen during the recording, requires the video to play in real time so a two hour file takes two hours, and typically produces a noticeably worse result. Extraction is faster, cleaner, and requires no supervision.

Common reasons to extract

• Transcription. Most transcription services charge by duration and accept audio only, and uploading a 2 GB video where a 30 MB audio file would do wastes a great deal of time.
• Podcasting from video. Recording an interview on video and publishing it as audio is a standard workflow, and the audio version is a separate deliverable.
• Music and sound from clips. Pulling a soundtrack, a sound effect, or a piece of dialogue out for separate use.
• Archiving what matters. A recorded lecture, meeting, or webinar is often worth keeping for the words alone, at a fraction of the storage.
• Listening on the move. Audio can play with the screen off and consumes a small fraction of the data.

A browser based video to MP3 converter handles this without uploading the video anywhere, which matters a great deal when the video is a recorded client meeting or an internal presentation. Since the extraction reads only the audio stream, it is also fast even on large video files.

Settings worth checking on extraction

Which audio codec is inside a video, and therefore whether the extraction can be a lossless copy, depends on the container and codec the video uses. Video File Formats Explained covers how to check that before you start.

Video audio is nearly always 48000 Hz, because that is the film and broadcast standard. Keep it there rather than resampling to 44100 Hz unless something downstream requires it. If the source is a single speaker, converting to mono halves the size for no audible loss. And for speech, 96 to 128 kbps is entirely sufficient, so there is no reason to extract a two hour meeting at 320 kbps.

Speed, Pitch, and a Real Podcast Workflow

Two more operations are worth understanding, and then it is worth seeing how the whole set fits together on a real job.

Changing speed without changing pitch

Naively speeding up audio raises its pitch, which is the chipmunk effect, because you are effectively playing the same waveform faster. Time stretching algorithms avoid this by breaking the audio into short overlapping windows and repositioning them in time while leaving the frequency content alone.

Speech tolerates this remarkably well. Speeding a lecture or a podcast to 1.25 or 1.5 times sounds natural and saves substantial time. Beyond about 2 times, consonants begin to blur and the processing becomes audible. Music tolerates it far less, since rhythmic material develops a distinctive smearing quality quite quickly.

Slowing audio down has practical uses too: transcribing difficult passages, learning a piece of music, or making a fast speaker intelligible.

Changing pitch without changing speed

The inverse operation shifts frequency while preserving duration. It is used to transpose music to a different key, to disguise a voice for anonymity, and to correct a recording that was captured at the wrong sample rate and came out both too fast and too high. In that last case, correcting the sample rate tag is the better fix if it is available, since it restores the original exactly rather than approximating it.

A complete workflow, start to finish

Suppose you have recorded a forty five minute interview over a video call. The recording is a video file, one speaker is much quieter than the other, there is five minutes of setup at the start, and you need a published podcast episode plus a transcript. Here is the whole job.

1. Extract the audio from the video. Pull the audio stream out rather than working with a large video file. Keep 48000 Hz. If both speakers were on one mixed track, keep stereo for now.
2. Trim the ends. Remove the setup conversation at the start and anything after the sign off. Cut at natural silences and apply short fades at each edit.
3. Fix the levels. If the speakers were recorded to separate tracks, normalize each one individually before mixing them together. If they are on one track, apply gentle compression to close the gap, then normalize the result.
4. Remove the worst of the noise. A gentle noise reduction pass helps if there is constant hum or air conditioning. Be conservative, since aggressive noise reduction gives voices an underwater quality that is worse than the noise.
5. Merge in the intro and outro. Normalize those separately first so they match the body of the episode, then join with a short crossfade.
6. Normalize the finished episode toward the target. Around minus 16 LUFS for stereo speech, or minus 19 for mono.
7. Export the master. Save a WAV or FLAC copy of the finished edit. This is what you return to if you ever need a different version.
8. Export the distribution file. MP3 at 128 kbps mono for a speech podcast, which keeps a forty minute episode around 37 MB. Use 192 kbps stereo if there is music.
9. Export a transcription copy. Mono at 64 kbps is more than enough for a transcription service and uploads in a fraction of the time.

Note that the lossy encode happens only at steps eight and nine, both times from the same lossless master. Nothing is ever encoded twice, which is the single most important structural property of a good audio workflow.

Why Browser Based Editing Works Now

Audio editing in a browser used to mean uploading a file to a server and waiting. That is no longer how it works, and the change is worth understanding because it affects both speed and privacy.

Browsers now include the Web Audio API, which provides real signal processing directly in JavaScript: gain, filtering, analysis, and sample level manipulation. Alongside it, WebAssembly allows compiled encoders and decoders to run at close to native speed inside a tab. Together these mean a browser can decode a file, process it properly, and encode the result without any server involvement whatsoever.

The practical consequences are worth stating plainly:

• Nothing is uploaded. The file is read from your disk into browser memory and written back out. For confidential interviews, legal recordings, medical dictation, or client work, this removes the entire question of what a remote service does with your data.
• There is no upload wait. A 200 MB file takes several minutes to send to a server before processing even begins. Local processing starts immediately, which usually makes it faster end to end for anything but very large files.
• No installation and no account. Useful on managed work machines, borrowed computers, and tablets.
• No queue and no file retention. Nothing sits on a server waiting to be deleted on somebody else's schedule.

The limits are real but narrow. Browsers cap available memory, so multi hour uncompressed files can be uncomfortable. Complex multitrack projects with automation and plugins still belong in a desktop application. And batch processing hundreds of files is a scripting job. For the everyday operations covered in this guide, none of those limits apply.

Mistakes That Quietly Ruin Audio

Encoding to a lossy format more than once

The most damaging and most common error. Every lossy encode discards data and adds artifacts, and the next encoder treats those artifacts as signal worth preserving. Always keep a lossless master and export each deliverable from it.

Normalizing before removing a spike

One loud bump sets the peak and prevents everything else from being raised. Find and reduce the spike first, then normalize.

Keeping stereo for a single voice

Doubles the file size to store two nearly identical channels. Convert speech to mono and halve the size with no audible difference.

Resampling repeatedly

Each sample rate conversion is a lossy calculation. Choose a rate at the beginning of the workflow and keep everything at it until the final export.

Over applying noise reduction

Heavy noise reduction removes parts of the voice along with the noise, producing a hollow, watery quality that listeners find more distracting than the original hiss. A little is helpful, a lot is worse than nothing.

Mastering far louder than the platform target

Streaming services normalize to their own loudness target, so anything louder simply gets turned down. You keep the distortion you added and gain none of the loudness.

Editing the only copy

Keep the original recording untouched. Every edit should produce a new file. Recordings of live events cannot be repeated, and an overwritten master is gone for good.

Frequently Asked Questions

Bringing It Together

Audio editing rewards a few structural habits far more than it rewards technical knowledge. Work from a lossless master and encode to a lossy format exactly once. Match the sample rate at the start and leave it alone. Fix levels by normalizing individual sources before combining them, not by normalizing the finished mix. Use mono for single voices. Trim aggressively, because nobody has ever complained that a recording was too short.

Everything else is choosing a number from a table. Speech at 128 kbps mono, music at 192 to 256 kbps stereo, 44100 Hz for music and 48000 Hz for anything from video. Those defaults cover the overwhelming majority of real work, and the browser handles all of it without asking you to install anything or hand your recordings to a server.