The details that matter when you use Reverse Audio fall into four predictable groups: the input file's container, codec, and size; the decoded audio's duration, channel count, sample rate, and sample budget; the output format, which is always a newly encoded 16-bit PCM WAV; and the local-only processing model, which keeps every byte inside the browser tab. Knowing these details up front turns a guessing workflow into a predictable one, because the tool reports a specific limit message instead of a partial result when any value is out of range. The reversal itself is a clean, sample-level operation: each accepted channel is read in full, reversed independently, and written back in interleaved WAV frame order at the original sample rate, with floating-point samples clipped to the -1 to 1 range and mapped to signed 16-bit PCM. Pitch, tempo, loudness, and container metadata are not normalized, altered, or copied. The sections below walk through each detail group, then show the exact three-step workflow, then explain what to verify in the finished WAV.
Input File Details That Decide Whether Decoding Starts
The file picker accepts common MP3, WAV, M4A, AAC, Ogg, and WebM audio MIME types, but the picker and the actual decoder are two different checks. The picker only looks at the container; the browser's Web Audio implementation decides whether the codec inside that container can actually be decoded. A familiar extension, for example an M4A or an Ogg file, can still fail to decode on a particular browser or operating system because the underlying codec is missing. When decoding fails, the Reverse Audio tool reports a decode error rather than producing a partial or silent file.
The compressed source must also be no larger than 50 MB. That limit applies to the file bytes you hand to the picker, not to the decoded length, so a small compressed file with a very long runtime can still be rejected later by the decoded-audio checks. A file that exceeds any input limit is not partially processed; it is refused with a specific message, and the previous download, if any, is cleared so an old success cannot be mistaken for a new result.
Decoded Audio Limits Worth Checking Before You Click Reverse
Once the file is decoded into raw samples, four interacting limits decide whether the reversal can run. The tool rejects the decoded audio rather than truncating it when any of these values is out of range.
| Limit | Allowed range | Why it matters |
|---|---|---|
| Decoded duration | 5 minutes or shorter | Protects the tab from long-form decoding jobs |
| Channel count | 1 to 8 channels | Common layouts from mono through 7.1 surround |
| Sample rate | 8,000 to 192,000 Hz | Covers telephone voice up to high-resolution audio |
| Channel-sample budget | 30,000,000 total samples (frames × channels) | Guards against unexpectedly large decoded arrays even from a small compressed file |
The channel-sample budget is the one detail that is easy to overlook. It is the number of frames multiplied by the number of channels, so a 48 kHz stereo clip that runs five minutes uses roughly 28.8 million channel samples and stays under the cap, while a 96 kHz eight-channel clip of the same length pushes past it. Check the four limits together, not just the file size in the picker, because the runtime and the channel layout are the deciding factors once decoding finishes.
How to Reverse Audio in Your Browser
- Choose a supported audio file up to 50 MB and optionally preview the original in the built-in player so you know what the source actually sounds like. Use the original preview to confirm the file is the right one, especially when several similar filenames live in the same folder.
- Select Reverse audio and wait while every decoded channel sample is reversed locally in the current tab. The same reverse function runs in both the production build and the test suite, so odd-length, even-length, and multichannel clips are all handled the same way.
- Preview the result, verify its duration and audio properties, then download the PCM16 WAV. The download is a freshly encoded file, not the original stream played backward, so listen to both the beginning and the end of the result before you treat it as final.
Output File Details: What the WAV Download Actually Contains
The downloaded file is always a new PCM16 WAV, never the original MP3, M4A, AAC, Ogg, WebM, or compressed WAV played backward. 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, positive full scale maps to 32767, and any out-of-range floating-point value is clamped before quantization. Because the output is uncompressed, the resulting WAV is often much larger than the source file, and reducing 32-bit float samples to 16-bit integers can change the numerical precision at the least significant bit.
Reversal preserves the decoded duration, sample rate, and channel count, and it moves every event to the position measured backward from the end. In a stereo file, the left channel and the right channel are reversed independently and then interleaved again in the correct WAV frame order, so a stereo input stays stereo. The tool does not normalize loudness, remove silence, change pitch intentionally, stretch time, or repair clipping, and the result is a fresh audio file rather than a tagged container, so album art, ID3 tags, chapters, loop markers, encoder settings, compressed bitrate, and other container-specific fields are not copied. When you also need fades, trimming, codec selection, metadata preservation, or mastering controls, finish those in a full audio editor.
Local Processing and URL Handling Details
Every step runs in the current browser tab. The file is read into an ArrayBuffer, decoded by Web Audio, reversed channel by channel, encoded as PCM16 WAV, and handed back through a temporary local object URL that the browser uses for the built-in preview and the download link. The original file and the finished WAV each get their own short-lived object URL, and selecting another file, running the operation again, or leaving the page releases those URLs so obsolete data is not kept around. The Web Audio context used for decoding is also closed after the operation or when the work is replaced by a new run.
Because decoding, reversal, and encoding happen locally, the file bytes, decoded samples, filename, and result are not uploaded to Lizely. That local workflow is one of the details worth keeping in mind for sound-design experiments, reverse speech inspection, transition effects, sample inspection, and end-of-recording checks; for a closer look at the privacy side of the same tool, see the guide on whether files are uploaded when you use Reverse Audio. For the underlying decoding step, the Web Audio decodeAudioData method defines the contract the browser follows when it decides whether a given file can be turned into samples at all.
Result Verification Details After the Download
Verification is the last set of details that matters, and it is where most silent mistakes are caught. Compare the duration, channel count, sample rate, and file size that the tool reports against the values you expected, then open the downloaded WAV in the editor or player where it will actually be used. Browser preview success does not guarantee that every older device or DAW supports the same WAV channel layout or high sample rate, so test in the destination environment rather than only in the browser. Listen to the beginning and the end of the reversed file: the end of the original is now the beginning of the download, and any artifact, click, or clipping that lived at the end of the source will surface at the start of the result. When the values match, the file opens cleanly, and both ends sound correct, the reversed WAV is ready to use.
If you're weighing options, What Details Matter When You Use an Audio Equalizer covers this in detail.