Correct reverse audio use means reversing every decoded sample in every channel of a file that meets the tool's published limits, then downloading a freshly encoded PCM16 WAV that you verify by checking its duration, channel count, sample rate, and playback before relying on it. The whole workflow runs in your current browser tab, so the file bytes, decoded samples, filename, and result never leave your machine. To use Reverse Audio correctly, you pick a supported source, confirm the input fits the size, duration, channel, and sample-rate ceilings, run the reversal, preview the output, and only then save the WAV. The file picker accepts common MP3, WAV, M4A, AAC, Ogg, and WebM audio MIME types, but actual codec support depends on your browser and operating system; a container can also hold a codec the browser cannot decode, in which case the tool reports a decode error rather than claiming every familiar extension will work. Skipping any of those checkpoints is how people end up with a clipped, mislabeled, or otherwise unusable result.
What "correct" reverse audio use actually requires
Reversing audio correctly depends on three things the tool can verify and one thing you must verify yourself.
First, the source must decode. The file picker accepts MP3, WAV, M4A, AAC, Ogg, and WebM MIME types, but actual codec support is determined by your browser and operating system. A familiar container can hold an unsupported codec, and the tool reports a decode error in that case instead of pretending every recognized extension is safe to submit.
Second, the source must sit inside the documented limits. If it does not, the tool refuses it outright and does not produce a partial result. The limits are not arbitrary; the channel-sample ceiling in particular protects the browser tab from a decoded array that quietly blew past the compressed file size.
Third, the output is always a newly encoded PCM16 WAV. That is not a side note; it changes the file format, the byte size, and what metadata survives. If you treat the download as if it were still an MP3 or M4A, you will not be using the result correctly.
Fourth, you must listen to and inspect the result. Browser preview success does not guarantee that every older device, DAW, or media player will accept the resulting WAV, especially when the sample rate is high or the channel layout is unusual. Open the file in the editor or player where it will actually be used.
Run the reverse audio workflow the right way
- Choose a supported audio file up to 50 MB from your computer using the file picker. Optionally preview the original in the browser to confirm it is the right clip before reversing anything.
- Confirm the input fits every documented limit: 50 MB or smaller compressed, no more than 5 minutes decoded, 1–8 channels, a sample rate between 8,000 and 192,000 Hz, and no more than 30 million channel samples in total (frames multiplied by channel count).
- Select the Reverse audio action and wait while every decoded channel sample is reversed locally. Do not close or refresh the tab while the operation is running.
- Preview the reversed result inside the tool and confirm it sounds the way you expected. The first thing you hear now is what used to be the last sound in the original.
- Verify the displayed duration, channel count, sample rate, and file size. Cross-check them against the original if you still have the source open.
- Download the resulting PCM16 WAV. The download is a freshly encoded file; it is not a bit-for-bit rewrap of the source. Old download links from earlier runs are released, so a previous success cannot be mistaken for the new one.
- Open the saved WAV in the editor, DAW, or player where it will be used to confirm compatibility. Browser playback success alone is not enough for older devices or unusual channel layouts.
Hard input limits that decide whether the operation can succeed
The tool enforces the limits below at the point of decoding. A file that exceeds any one of them is rejected with a specific message and is not partially processed.
| Limit | Value | What it protects |
|---|---|---|
| Compressed file size | 50 MB | File reading and the ArrayBuffer that holds the bytes |
| Decoded duration | 5 minutes or shorter | Time spent reversing every sample and encoding the WAV |
| Channel count | 1 to 8 channels | Interleaved WAV frame writer and the decodeAudioData call |
| Sample rate | 8,000 to 192,000 Hz | Output WAV header fields and downstream player support |
| Channel samples in total | 30,000,000 (frames × channels) | Size of the decoded Float32Array kept in memory |
When all of these hold, the tool can guarantee that no samples are deliberately skipped, shortened, or capped inside an accepted file. If a limit fails, the right next step is to trim the source with a tool such as the Audio Cutter, reduce the channel count in your DAW, or convert the sample rate before retrying.
What the output is — and what it deliberately is not
Because the download is always a freshly encoded PCM16 WAV, several source properties do not survive. Knowing this ahead of time is part of using reverse audio correctly.
| Property | Behavior in the output |
|---|---|
| Container and codec | Always PCM16 inside a WAV RIFF container; MP3, AAC, Ogg, and WebM are not preserved |
| Bitrate | Not applicable — the output is uncompressed PCM at 16-bit |
| Sample rate | Preserved when it sits inside the 8,000–192,000 Hz window |
| Channel count | Preserved when it is between 1 and 8 |
| Duration | Equal to the decoded duration of the source; reversal preserves length |
| Tags, artwork, chapters, loop markers, encoder settings | Not copied; the output is a fresh file |
| Loudness, silence, pitch, time stretching | Not adjusted; only sample order changes |
| Numerical precision | Reduced to 16-bit; samples are clipped to −1 to 1 before mapping to signed PCM |
Each browser-decoded floating-point sample is clipped to the range from −1 to 1, mapped to signed 16-bit PCM, and written little-endian. Negative full scale maps to −32768 and positive full scale maps to 32767. WAV is therefore often much larger than the compressed source, and the 16-bit step can change numerical precision at the lowest bits.
Verify the reversed WAV before you trust it
The single biggest reason a "reversed" file looks wrong is that the verification step was skipped. A short, deliberate check sequence catches the common failures: channel order being reversed instead of time, the center sample of an odd-length clip being dropped, or an invalid RIFF header being written.
After the download completes, listen to the first 200 ms of the result. That section corresponds to the last 200 ms of the original. If you recognize the tail of your source playing in reverse, the time axis was reversed correctly. Then listen to the last 200 ms. That section corresponds to the opening of your source; if the head of the original is recognizable but mirrored, the result is structurally correct.
Confirm the duration matches the original to within a single sample. Reversing preserves length, so any mismatch points at a decoding or encoding problem. Open the file's properties panel in your player: the channel count and sample rate should match what the tool reported, and stereo sources must remain stereo with the left and right channels unchanged relative to each other. Finally, confirm the file size is consistent with PCM16 at the displayed sample rate, channel count, and duration. A file that is dramatically smaller than expected may have been truncated, and a dramatically larger one may have been written with the wrong header.
The tool's own reverseChannels and encodePcm16Wav implementations are exercised by odd and even frame counts, multiple channels, source-array immutability checks, and RIFF/WAV golden tests that inspect the RIFF, WAVE, fmt, and data fields, byte rate, block alignment, little-endian PCM bytes, and stereo interleaving. Those checks catch common failures such as reversing channel order instead of time, dropping the center sample of an odd-length clip, or writing an invalid header. If those tests would fail, the production code is the same code that produced your file, so a clean verification at your end lines up with the published guarantees.
Why local processing matters for correct use
Correct use also means understanding where the work happens. The Reverse Audio tool reads the file, decodes it with the Web Audio API, reverses every channel sample, encodes a PCM16 WAV, and creates the download entirely inside your current browser tab. Nothing is uploaded to Lizely, no remote conversion service is called, and FFmpeg is not installed in the background. The browser retains the original sample rate and channel count only when those values fit the stated limits; outside those limits, the operation is refused rather than silently producing a partial result.
This matters for verification because the only artefacts that exist after the operation are the temporary object URLs for the built-in preview and the WAV download. Selecting another file, running the operation again, or leaving the page releases obsolete URLs, which means a previous success cannot silently masquerade as the new result. The Web Audio context used for decoding is also closed after the operation or when the work is replaced, and job and mounted-state guards prevent stale asynchronous work from overwriting newer results. If you want a second opinion on whether reverse audio is even the right effect for what you are trying to do, the decision guide at How Do I Decide Whether I Need to Use Reverse Audio walks through the cases where reversal helps and the cases where a different tool is the correct choice.
For a deeper look, see Plan the Steps Needed to Use Reverse Audio Locally.