After processing a file with Reverse Audio, the result is always a freshly encoded 16-bit PCM WAV, and you verify it by previewing the playback inside the tool, reading its duration, sample rate, channel count, and file size, then opening the downloaded WAV in a separate player or audio editor. Reversal preserves the decoded duration, sample rate, and channel count from the accepted input, but it always rewrites the container, so tags, artwork, encoder settings, and the original compressed codec are not carried into the download. A successful preview proves only that the current browser tab decoded and reversed your samples; it does not prove that every other device will accept the same WAV layout or high sample rate. The verification step therefore has two parts: confirm what the tool reports about its own output, then open that output somewhere independent and confirm what you hear matches what you expected. Treat those two checks as a single workflow rather than a single action, and the on-page preview becomes a fast first filter rather than the final word.
What "Checking the Result" Means in This Tool
A reversed file differs from the source in three predictable ways. The bytes become 16-bit PCM little-endian WAV, the original metadata is stripped, and the audible waveform now runs from end to beginning. "Checking" therefore means three concrete things: confirm that the file plays back at all, confirm that what you hear is the source played backward, and confirm that the numbers the tool reports (duration, sample rate, channels, file size) match what a second program reports when you open the same WAV. Skipping any one of those three usually leaves a quiet failure mode in place, such as a stereo file that has been turned into mono, or a duration that has been silently truncated.
The browser tab is the only place where the reversal happens. The on-page preview uses a temporary local object URL for the original file, and the finished WAV receives a separate temporary download URL. Selecting another file, running the operation again, or leaving the page releases those URLs, so the on-page player is only a quick check. The downloaded file is the only durable artifact, which is why verification moves outside the tab as soon as the on-page check looks reasonable. The Web Audio context used for decoding is also closed after the operation or when work is replaced, so a stale preview cannot be confused with a new result.
Verify the Reversed Audio Step by Step
- Open the Reverse Audio page in your browser tab and choose the same file you already processed, or load the file you plan to reverse.
- Use the built-in preview to listen to the original and note its duration in seconds before reversing.
- Select Reverse audio and wait while every decoded channel sample is reversed locally in your tab. Nothing is sent to a remote server during this step.
- Preview the result and compare it against the original preview. The first audible event of the original should now appear at the end of the result, and the last event should appear at the start.
- Read the duration, sample rate, channel count, and file size the tool displays for the reversed file. They should be close to the original's values, with no samples skipped, shortened, or capped inside an accepted file.
- Download the PCM16 WAV and open it in a separate audio editor or player such as Audacity, Reaper, or ocenaudio.
- In the editor, check the header-reported sample rate and channel count, listen to the first and last half-second of the file, and confirm that the reversal is what you intended before using the WAV anywhere downstream.
Which Audio Properties Should and Should Not Match
The reversal is a time-domain operation on decoded samples, so it preserves frame count, sample rate, and channel count, while changing container, bit depth, and metadata. Knowing which is which lets you spot a real failure quickly instead of chasing a non-issue.
| Property | After Reversal | Why It Behaves This Way |
|---|---|---|
| Duration | Unchanged (within sub-frame rounding) | Reversal moves samples but keeps frame count |
| Sample rate | Unchanged when between 8,000 and 192,000 Hz | Browser decodes at the source rate and the WAV header copies it |
| Channel count | Unchanged when between 1 and 8 | Each accepted channel is reversed independently and written back in interleaved frame order |
| Bit depth | Always 16-bit PCM | Output is a freshly encoded PCM16 WAV regardless of source depth |
| File container | WAV (RIFF/WAVE/fmt /data) | The encoder writes PCM data only; the original codec is not retained |
| Tags, artwork, chapters | Stripped | Only PCM samples are written to the output file |
| Compressed bitrate | Not present | WAV has no compressed bitrate field |
| Pitch and tempo | Unchanged | Reversal does not resample or stretch time |
A stereo source stays stereo across the reversal: the left channel samples are reversed independently, the right channel samples are reversed independently, and the two channels are interleaved again in the correct WAV frame order. Reversing channel order instead of time is the kind of failure that shows up the moment you compare the first and last half-second against the original, which is why that comparison is built into the verification workflow. 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, with negative full scale mapping to -32768 and positive full scale mapping to 32767. That step can change numerical precision relative to higher-depth sources, so a small loss of low-level detail in the WAV is expected.
Decode Errors vs Successful Reversal
The file picker accepts common MP3, WAV, M4A, AAC, Ogg, and WebM audio MIME types, but actual decoding depends on the visitor's browser and operating system. A familiar container can still hold a codec the current browser cannot read, in which case the tool reports a decode error rather than treating the file as supported. A decode error is not the same as a reversal error: it means the browser could not turn the compressed bytes into samples, so the reverse operation never ran. When Web Audio rejects the data, the tool surfaces that rejection instead of claiming that every file with a familiar extension must work, and input acceptance and successful decoding are treated as separate checks.
Limits are explicit and enforced on the decoded audio, not just on the compressed bytes. A file that exceeds any limit returns a specific message and is not partially processed. Changing files or retrying also clears the previous download first, so an old success cannot be mistaken for a new result after an error.
| Limit | Value |
|---|---|
| Compressed input size | Up to 50 MB |
| Decoded duration | Up to 5 minutes |
| Channel count | 1 to 8 channels |
| Sample rate | 8,000 to 192,000 Hz |
| Total channel samples | Up to 30,000,000 (frames multiplied by channels) |
The channel-sample budget is what protects the tab from unexpectedly large decoded arrays even when a compressed source file looks small. A four-minute mono clip at 44.1 kHz stays well under the budget; a four-minute 8-channel clip at 96 kHz exceeds it. If your decode fails or returns an error, reduce the duration or the channel count rather than re-trying the same file, since the limit is checked against the decoded audio rather than the compressed bytes.
Cross-Checking the WAV Outside the Browser
A second program gives an independent reading of the same file. The reverse encoder writes a standard RIFF header with "WAVE", "fmt ", and "data" chunks, and any WAV-aware editor will read the sample rate, channel count, and bit depth from that header. Open the download in a player or editor such as Audacity, Reaper, ocenaudio, or any DAW that can import WAV, and check the values it reports against what the on-page tool reported. The core transformation and encoder are shared by production and isolated tests; reversal tests cover odd and even frame counts, multiple channels, and confirmation that source arrays are not mutated, while WAV golden tests inspect the RIFF, WAVE, fmt, and data fields, byte rate, block alignment, little-endian PCM bytes, and stereo interleaving.
Browser preview success does not guarantee that every older device supports the same WAV channel layout or high sample rate. A multichannel source above 48 kHz may preview cleanly in a modern browser but still refuse to import on a phone or an older mixer. That is why the second check belongs in a real editor, not in the same tab that produced the file. Web Audio decoding and WAV encoding are described in the MDN reference for BaseAudioContext.decodeAudioData, and the underlying buffer structure is defined in the Web Audio API specification for AudioBuffer; those two sources cover the decode path the tool uses and explain why codec support varies between browsers.
When the Result Looks Wrong
Four patterns come up often during verification, and each has a known cause.
- Silent or near-silent playback. The decode succeeded but the samples sit at zero, which usually means the source itself was silent at the point where it begins (now the end) and silent where it ends (now the start). Confirm by reversing the original in a different program; if both tools give silence, the input is the cause rather than the reversal.
- Duration off by a fraction of a second. Web Audio decoding can round the last partial frame, so very short clips may show a one-frame mismatch. This is expected behavior from the decoder rather than a reversal failure, and the tool does not silently truncate or extend the file.
- Mono where stereo was expected. The decoded channel count is preserved, so if your WAV is mono, the input was mono as decoded by the browser even if the container reported more channels. Re-export the source or pick a different container so the browser can decode more than one channel.
- A loud click at the very start. Reversal does not add fades, normalize loudness, or repair clipping. Any DC offset or leading transient in the original becomes a trailing transient in the result, and that is by design. For fades, trimming, codec choice, or loudness control, hand the WAV to a dedicated editor; the tool does not perform mastering work on the reversed output.
For a reliable workflow, keep the source file, listen to the original preview, create the reversed WAV, and listen to the beginning and end of the result. Confirm the duration, channel count, sample rate, and file size displayed by the tool, then confirm the same numbers in a separate editor. If anything still looks off, the guide on avoiding mistakes when you use Reverse Audio locally walks through the specific failure modes with sample-level detail, including how to recognize a reversed-channel-order failure versus a clean time reversal. Treat verification as a deliberate two-step check rather than a single click, and the reversed WAV will be safe to drop into any downstream player, editor, or device that accepts PCM16 WAV.
If you're weighing options, How Do I Choose the Right Approach to Use Reverse Audio covers this in detail.