Clean up a voice recording

What it does, in order

1. Decode at 48 kHz. The browser's own decoder (Web Audio, in an OfflineAudioContext running at 48,000 samples a second) turns the file into samples. A 44.1 kHz file, or a 16 kHz phone memo, is resampled to 48 kHz on the way in, because the noise suppressor only works at that rate. A video file gives up its sound track the same way. Stereo stays stereo; a file with more than two channels keeps its first two.
2. Reduce noise, if ticked. RNNoise goes through the sound 480 samples (10 ms) at a time and turns down the parts of the spectrum it judges to be noise rather than voice. Each channel is cleaned on its own.
3. Trim silence, if ticked. The sound is cut into 10 ms slices; the first and last slice louder than both -55 dBFS and 40 dB below the loudest slice mark where speech starts and ends. 0.2 s is kept before and after, with a 10 ms fade, so words do not start abruptly. Pauses in the middle are left alone.
4. Set the volume. The integrated loudness is measured and the whole recording is turned up or down to the target. If that pushes any true peak above -1 dBTP, a limiter pulls just those peaks down (it looks 3 ms ahead and lets go over about 80 ms). Limiting takes a little loudness away, so the page measures again, corrects the gain and repeats until the result is within 0.05 LU of the target, or gives up after 8 tries and shows what it got. It will not add more than 40 dB: a file that would need more is nearly silent (or, after noise suppression, had no speech in it), and turning it up would only make hiss loud, so the volume is left alone and the page says why.
5. Measure again. The After column is measured on the finished samples, rounded to 16 bits exactly as the WAV file stores them. Nothing in that table is a promise; it is a reading.

Which volume to pick

• -16 LUFS: podcasts and anything people play on a phone. Apple's podcast guidance asks for -16 LKFS (LKFS and LUFS are the same unit) with peaks no higher than -1 dB. Good default for a voice memo you will send on.
• -14 LUFS: what Spotify and YouTube turn music and uploads to by default. A voice track mastered here will not be turned up by them; it may be turned down a little.
• -23 LUFS: EBU R128, the European broadcast standard (with a true peak of at most -1 dBTP). Sounds quiet on a phone. Pick it when a broadcaster or an editor asks for R128.
• Leave the volume as it is: only noise suppression and trimming are applied; the table still shows before and after readings.

A worked example, with round numbers: a voice memo recorded at arm's length reads -31.4 LUFS with a true peak of -12.8 dBTP. For -16 LUFS it needs +15.4 dB. That would put its loudest peak at +2.6 dBTP, which would clip, so the limiter holds those few peaks at -1 dBTP; the page then adds a fraction of a dB more gain so the integrated loudness still lands on -16.0. Recordings with a lot of headroom between speech and peaks (a clap, a plosive "p", a laugh) need the most limiting, and heavy limiting can sound squashed. If the After row shows it had to hold peaks down by more than about 6 dB, a lower target will sound more natural.

Noise suppression: what it is good at, and what it breaks

The noise suppressor is RNNoise, a small neural network from Xiph.Org (the Opus and Ogg people), trained on speech mixed with everyday noise. It is the same kind of suppressor video-call apps use. Here it runs as WebAssembly inside this tab, from a copy stored on this site (@shiguredo/rnnoise-wasm 2025.1.5, Apache-2.0, containing RNNoise under the BSD-3-Clause licence). It is loaded only when you tick the box.

• Good at steady noise behind a voice: fan, air conditioning, computer hum, road rumble, room hiss, a distant crowd. In this site's test, a stretch of pure noise came out more than 10 dB quieter (the test requires at least 10 dB).
• Made for speech, and it can damage music. It keeps what it recognises as a voice and turns down everything else, so music, singing with instruments, sound effects and a pure tone are treated as noise: they come out thin, warbling or almost silent. Do not use it on a music recording, and turn it off if your recording has music under the voice.
• Only at 48 kHz. RNNoise was built for 48 kHz audio. Every file is resampled to 48 kHz before it runs, and the saved file is 48 kHz whatever the original rate was.
• It cannot remove echo or room reverb, another person talking, or clipping that is already in the recording. Very loud noise close to the voice, such as wind on the microphone, can make the voice itself watery.
• It adds a fixed 20 ms delay, which the page removes, so original and cleaned stay in step for A/B listening and trimming.
• It is slow on a phone. It runs on the page's main thread in short bursts so the tab stays usable: on this site's test server (in Node, the same WebAssembly), one minute of mono audio took about 8 seconds; a phone may take several times longer. Stereo takes twice as long.

When you record on this page, the browser is asked to switch off its own echo cancellation, noise suppression and automatic gain, so that the Original you hear is really the raw microphone and the A/B comparison is honest. Some phones ignore that request.

How loudness and true peak are measured

Both numbers follow ITU-R BS.1770-4, the method behind EBU R128, ATSC A/85 and the LUFS targets streaming services publish:

• K-weighting: the sound goes through two filters, a +4 dB shelf above about 1.7 kHz (the head makes those frequencies seem louder) and a high-pass at about 38 Hz (rumble counts for little). At 1 kHz the two together add about 0.7 dB, which is why the formula subtracts 0.691.
• Blocks and gating: the mean square is taken over 400 ms blocks that start every 100 ms. Blocks below -70 LUFS (silence) are dropped, then blocks more than 10 LU below the average of the rest (pauses, breaths) are dropped too, and the remainder is averaged. So a long pause does not make a recording read quieter.
• Channels: left and right each count with weight 1. A mono recording is measured as one channel, not as "dual mono". A mono file played on both speakers of a stereo system is sometimes measured as two identical channels, which reads 3 LU louder. This page does not do that. If your platform measures mono as dual mono, a file made here at -16 LUFS would read -13 LUFS there.
• True peak: samples are only snapshots, and the wave between two samples can swing higher than either, which clips in a converter or an MP3/AAC encoder. The page interpolates 4 samples for every original one with the 48-tap filter given in BS.1770-4 Annex 2 and takes the highest. That is what dBTP means; the plain sample peak can be up to about 3 dB lower.
• Checked against known answers: a 1 kHz sine of amplitude 0.10012 (-19.99 dBFS) reads -23.0 LUFS in mono, the value the formula gives, and a 12 kHz sine whose samples all sit at 0.707 (-3.0 dBFS sample peak) reads 0.0 to +0.1 dBTP, its real peak.

Anything shorter than 0.4 s cannot be measured (there is not a single block), and a recording of pure silence has no loudness at all; the page says so instead of inventing a number.

Saving

• WAV works in every browser: 16-bit PCM, 48 kHz, 5.8 MB a minute in mono. The After numbers describe exactly this file.
• M4A (AAC, 96 kbit/s, about 0.7 MB a minute) where the browser has an AAC encoder for web pages, such as Chrome and Edge on Windows and macOS. It opens everywhere.
• Opus in an MP4 file (64 kbit/s, about 0.5 MB a minute) where there is an Opus encoder but no AAC one, for example Chrome on Linux. It plays in browsers, VLC, Windows and Android; Apple software may not open it.

AAC and Opus are lossy: decoding them can land a peak a few tenths of a dB higher than in the WAV, and the page does not re-measure them. The -1 dBTP ceiling is there to leave room for exactly that.

What happens to your recording

Opening a file gives this tab a private blob: address for it. Decoding, cleaning, measuring and encoding all happen in the tab's memory; the saved file is built there too, and Download saves it like any other download. This page has no upload code and no server to upload to, and it uses no browser storage, so closing the tab forgets everything. The only other request it makes is to fetch the noise suppressor from this same site when you tick the box, plus an anonymous, cookie-free page-view count (GoatCounter) that never sees your audio. From the recorder, a voice recording's "Clean up this recording" button opens it here directly, tab to tab in memory; the trimmer has the same button under a saved sound file.

What it cannot do

• It cannot clean music. The noise suppressor is made for speech and treats instruments as noise.
• No echo or reverb removal, no de-clipping, no separating two voices, no removing a single sound such as a cough or a door.
• No adjustable strength: suppression is on or off. No equaliser, de-esser or compressor beyond the peak limiter.
• It works at 48 kHz only and saves 48 kHz, so a 44.1 kHz file is resampled. It saves at most two channels.
• It does not cut or remove pauses in the middle; use the trimmer for that. It saves sound only, even when you open a video.
• Memory: the page holds the recording several times over as 32-bit samples, roughly 50 MB per minute of stereo. An hour-long file is fine on a laptop and too much for many phones.
• It opens only what this browser can decode: Apple Lossless (ALAC) only in Safari, old AMR phone memos in almost no browser.

What works where

Version numbers are the first release with the feature, from MDN browser-compat-data (the same source as the trimmer's table), checked 2026-09-25; they are not test results. *MDN tracks the encoder API, not which codecs it offers: whether AAC is there depends on the operating system and the build. The “This browser” column asks the browser you are using now. WAV needs no encoder and works wherever decoding does.

What has actually been tested

One browser: headless Chrome on Linux, driven by test/clean-audio.test.cjs in this site's repository on 2026-09-25. It opened a noisy 48 kHz test WAV, turned noise suppression on, chose -16 LUFS, cleaned it and saved a WAV and, since Chrome on Linux has no AAC encoder, an Opus-in-MP4 file. The WAV's header and sample count were checked, and the tab made no request to any other site from the moment the file was dropped until it was saved. The same test checks the meter and normaliser in Node: the 1 kHz sine above reads within 0.1 LU of -23 LUFS, a speech-like test signal at -30 LUFS with sharp peaks comes out at -16 ± 0.2 LUFS with its true peak at or below -1 dBTP (the limiter had to work to get there), and RNNoise, run from the copy vendored on this site, lowers a noise-only stretch by at least 10 dB. Firefox, Safari, phones and real voice recordings have not been tested by machine; the M4A path was not tested because that Chrome has no AAC encoder.