How to fix clipping audio before you publish
- Step 1Check whether your clipping is in the source or on encode — If the file already crackles before any upload, the clipping is baked into the samples and the limiter can't undo it — re-export a clean version from your DAW with more headroom. If it only distorts after publishing, that's encode-stage overshoot, which this tool prevents.
- Step 2Confirm Pro access — The limiter requires Pro. Free accounts can't run it. Pro handles up to 200 MB / 120 minutes; Pro + Media and Developer go to 100 GB with no duration cap.
- Step 3Drop the file you're about to publish — FFmpeg WebAssembly processes it locally. Accepted input is any audio FFmpeg can decode (MP3, WAV, FLAC, M4A/AAC, OGG, Opus). The audio stays in your browser tab.
- Step 4Set the ceiling to leave publishing headroom — -1.0 dBTP · standard is the safe default. If the destination re-encodes aggressively at low bitrate, -1.5 dBTP · safer gives more margin against overshoot-driven clipping.
- Step 5Pick the output format your platform wants — WAV/FLAC for a clean lossless deliverable a host will re-encode; MP3 or M4A (192 kbps) for a direct publish file. The ceiling is applied before encoding, so the published file carries the headroom.
- Step 6Verify the reported peak, then publish — The result panel shows the achieved peak in dBFS from ebur128. With it safely under full scale (at or near your ceiling), the file won't clip on the platform's encode. Publish with confidence.
Clipping: what this tool can and can't fix
The single most important thing to understand before publishing — limiting prevents new clipping but does not repair clipping already in the samples.
| Type of clipping | Cause | Can this tool fix it? | What to do |
|---|---|---|---|
| Encode-stage overshoot | Lossy codec reconstructs inter-sample peaks above 0 dBFS | Yes — prevents it | Limit to -1.0/-1.5 dBTP before publishing |
| Baked-in clip on the master | Mix bounced above 0 dBFS, samples already flat-topped | No — can't undo | Re-export a clean source with headroom |
| Recording clip | Mic/preamp/interface clipped at capture | No — can't undo | Re-record, or accept the distortion is in the take |
| Sum-of-tracks clip in DAW | Master bus exceeded 0 dBFS before bounce | Prevent on next bounce | Lower the master fader, re-bounce, then limit |
Ceiling choices for clean publishing
The four ceilings the UI offers, framed by how much codec headroom each leaves before publish.
| UI option | Headroom left | Best for |
|---|---|---|
| -1.0 dBTP · standard | 1 dB | Most platforms; the safe default |
| -1.5 dBTP · safer | 1.5 dB | Low-bitrate hosts that re-encode hard |
| -2.0 dBTP · Amazon | 2 dB | Amazon Music's tighter spec |
| -0.3 dBTP · loud | 0.3 dB | Files that play back without further encoding |
Cookbook
Real publish-day scenarios, including the cases where the right answer is 're-export, don't limit'.
File clean in DAW, distorts after publishing
The classic encode-stage clip: 0 dBFS bounce sounds fine locally but crackles once the host re-encodes. Limiting to -1.0 dBTP before publish gives the encoder room.
Before: bounce.wav at 0.0 dBFS → publish → host MP3 re-encode → playback crackles (decoded peak +0.7 dBFS) After: ceiling -1.0 dBTP, output WAV ebur128 peak: -1.0 dBFS → publish → no crackle Encode-stage clipping prevented.
Master already clipped — limiter can't save it
A file that was bounced well above 0 dBFS has flat-topped, distorted samples. The limiter pulls the level down but the distortion is already in the waveform; the result is a quieter distorted file. The fix is a clean re-export.
Input: hot-master.wav, samples flat-topped at 0 dBFS
Ceiling: -1.0 dBTP
Output: -1.0 dBFS peak, BUT distortion still audible.
→ Correct fix: re-bounce from the DAW with the master
fader lowered, then limit the clean bounce.Aggressive low-bitrate host — use -1.5 dBTP
A host that re-encodes to 96 kbps can overshoot more than a high-bitrate platform. The safer ceiling adds margin so even the harder encode stays clean.
Input: episode.wav (clean) Ceiling: -1.5 dBTP · safer Format: MP3 (192 kbps) Output: episode-limited.mp3, peak ~-1.5 dBFS Survives the host's 96 kbps re-encode without clipping.
Last-mile safety on a normalized master
After loudness normalization, peaks should already be under -1 dBTP, but this final limiter pass guarantees nothing drifted above the ceiling before you publish.
Step 1: loudness-normalizer (Apple Podcasts: -16 LUFS, -1 dBTP) Step 2: true-peak-limiter, ceiling -1.0 dBTP, WAV Result: peak confirmed -1.0 dBFS before publish. Belt-and-braces against encode clipping.
Verify a guest-submitted file before you publish it
When a contributor sends audio you're about to publish under your name, run it through at -1.0 dBTP to both check and enforce the ceiling in one step.
Input: guest-segment.wav (provenance unknown) Ceiling: -1.0 dBTP Format: WAV Output peak: -1.0 dBFS If it engaged, the file was hotter than -1 dBTP and is now safe; if it didn't, the file was already compliant. Either way: publishable.
Edge cases and what actually happens
Clipping is already baked into the source
Cannot repairIf the samples are flat-topped from a bounce or recording above 0 dBFS, limiting only lowers the overall level — the distortion stays in the waveform. There's no declipping here. The only real fix is re-exporting a clean source from the DAW with headroom, or re-recording. This tool prevents new clipping; it does not undo existing clipping.
Free account
Requires ProThe limiter is Pro-gated; Free accounts can't run it and see a 'requires a Pro subscription' message. Pro processes up to 200 MB / 120 minutes per file; higher tiers go to 100 GB with no duration cap.
Output still distorts after limiting
Source issueIf the limited file still sounds distorted, the clipping was in the source, not from encode overshoot. Confirm by listening to the original before any upload — if it crackles there, re-export a clean master. Limiting a distorted source produces a quieter distorted file, not a clean one.
Expecting de-clip / clip repair
Wrong toolThis is a brickwall peak limiter, not a clip-restoration tool. JAD's audio suite has no de-clipper. The right workflow is to prevent clipping at the source and use this tool as a pre-publish ceiling. For loudness issues use loudness-normalizer; for level boosting use volume-normalizer.
Reported peak slightly above the ceiling
By designalimiter is sample-peak based; ebur128 reads true-peak-style and can sit a fraction higher. After a -1.0 dBTP limit a reading of around -0.9 dBFS is normal and still safe for publishing — that's the headroom margin working as intended. Choose -1.5 or -2.0 dBTP for a larger guaranteed gap.
File over the Pro 200 MB / 120-minute cap
Limit exceededPro checks size and duration independently. A long lossless deliverable can exceed 200 MB before 120 minutes. Convert to FLAC with wav-to-flac to shrink it, split with audio-splitter, or move to Pro + Media (100 GB, unlimited duration).
Re-encoding adds a second lossy generation
Quality noteLimiting a lossy file and outputting lossy again stacks generations and can soften quality. Before publishing, prefer to limit from a lossless source (WAV/FLAC) and output lossless, letting the platform do the single lossy encode. The 192 kbps MP3/M4A outputs here are fine for direct publish but aren't ideal as an intermediate.
Whole track triggers constant limiting
Source too hotIf the limiter engages on nearly every sample, the master is far too hot and will sound squashed. Lower the master level in the DAW and re-bounce, or normalize loudness first so the limiter only catches occasional transients. Constant limiting is a mixing symptom, not a tool problem.
Video file submitted for publish
Audio-only toolThis tool accepts audio. If you're publishing a video's audio, extract it first with video-to-wav, limit it, then re-mux in your editor. The limiter doesn't process video containers.
ebur128 verification can't parse the output
Verification errorA corrupt or truncated source can leave the output unreadable by the verification pass, reported as a true-peak parse failure. The limiting completed; the metering failed on bad data. Re-export a clean file from the DAW and run it again.
Frequently asked questions
Can this tool remove clipping that's already in my file?
No. If the clipping was recorded or bounced into the samples (flat-topped waveforms), it's permanent — limiting only lowers the level, leaving a quieter distorted file. This is a brickwall peak limiter that prevents new clipping forming on encode, not a clip repairer. For baked-in distortion, re-export a clean source from your DAW.
Then how does it 'fix clipping before publish'?
It fixes the most common publish-day clipping: encode-stage overshoot. Lossy codecs reconstruct peaks above 0 dBFS on decode; limiting your master to -1 dBTP first leaves headroom so that overshoot never clips. The clipping is prevented, not repaired — which is exactly what you want before hitting publish.
How do I tell which kind of clipping I have?
Listen to the file before any upload. If it crackles already, the clipping is in the source — re-export clean. If it only distorts after the platform processes it, that's encode overshoot, which this tool prevents by leaving headroom.
What ceiling should I publish at?
-1.0 dBTP (the default) is safe for most platforms. Use -1.5 dBTP if the host re-encodes at low bitrate, or -2.0 dBTP for Amazon Music. -0.3 dBTP only suits files that play back without further encoding.
What's actually applied to my audio?
FFmpeg's alimiter look-ahead brickwall limiter at your chosen ceiling (converted from dB to linear amplitude), then a verification pass with ebur128=peak=true that reports the achieved peak in dBFS. It runs as WebAssembly in your browser — nothing is uploaded.
Is it free?
No — it requires a Pro subscription. Free accounts can't run it. Pro processes files up to 200 MB / 120 minutes; Pro + Media and Developer go to 100 GB with no duration cap.
Does my pre-release audio leave my computer?
No. FFmpeg runs locally in your browser via WebAssembly and the audio stays in the tab. Only an anonymous usage counter is recorded for dashboard stats, never the audio content.
Will limiting make the file sound worse?
Done on a clean source, limiting is transparent — it only touches peaks that breach the ceiling. It sounds worse only if the master was already too hot (constant limiting squashes transients) or already clipped (the distortion is pre-existing). Limit a clean, headroom-leaving bounce and it should be inaudible.
Should I limit before or after normalizing loudness?
Normalize first, then limit. The loudness-normalizer applies its own true-peak limit in pass two, so running this tool afterward is a final guarantee the ceiling holds before publishing. Limiting first then normalizing can re-raise peaks past the ceiling.
What output format should I publish?
If the platform re-encodes, hand it WAV or FLAC so only one lossy generation occurs. For a direct publish file, MP3 or M4A (192 kbps) is fine. The ceiling is applied before encoding regardless, so the headroom is in the published file.
Can I check a file is publish-safe without changing it?
Effectively yes — run it at -1.0 dBTP. If it's already under the ceiling the limiter changes nothing audible and the reported peak confirms it's safe. If it was hotter, the tool brings it into spec. Either way you end up with a publishable file and a verified peak.
Why does the reported peak not read exactly my ceiling?
alimiter enforces a sample-peak ceiling while ebur128 measures true-peak-style, so the verification can read a fraction above the linear ceiling. That small gap is the intended safety margin — it's why -1 dBTP, not 0, is the publishing standard.
Privacy first
Every JAD Audio tool runs entirely in your browser via FFmpeg (WebAssembly) and RNNoise. Your audio files never leave your device — verified by zero outbound network requests during processing.