To change pitch without losing quality in the browser, the file is decoded with Web Audio, resampled through an OfflineAudioContext at the equal-tempered ratio 2^(n/12) where n is the semitone offset, and exported as an uncompressed PCM16 WAV. Because that ratio also drives the playback speed, raising pitch shortens the audio and lowering pitch lengthens it by the same factor. Pitch shifts executed this way are sample-rate pure at the source, because the original buffer is never re-recorded, but the resampled output can expose aliasing that was masked in the original. The choice between staying in the browser and shipping the file to a desktop DAW comes down to whether the project needs pitch alone, pitch with locked tempo, or pitch plus a transparent master. Audio Pitch Changer targets the first of those three cases and stays honest about the second by surfacing the math in plain language on the page.
Audio Pitch Changer follows that pipeline in the current browser tab and targets the practical task behind the keyword: a user has one audio file, wants a different musical pitch, and wants the result to stay in the browser rather than travel to a server. The product contract states that nothing is uploaded, the file is decoded locally, the offline render runs at the decoded sample rate, and the download is a freshly encoded WAV. The next sections explain the math behind the semitone slider, the three-step procedure, the input and output limits, and the cases where this approach is the wrong tool.
How the Equal-Tempered Pitch Formula Works
Pitch in this tool is governed by twelve-tone equal temperament, the same tuning system used by modern digital keyboards and MIDI. McGill University's course material on MIDI and frequency conversion states that an octave contains twelve equal semitones, each with a frequency ratio of 2^(1/12), and that one semitone equals 100 cents. The W3C Web Audio specification defines the matching cents relationship in the AudioBufferSourceNode playback algorithm, where detuning contributes a factor of 2^(detune/1200).
Translating between cents and semitones (one hundred cents per semitone) collapses both formulas into the simpler form used throughout this article: playbackRate = 2^(n / 12), where n is the integer semitone offset.
MDN documents playbackRate as a multiplier on the original sampling rate: a value below one slows the audio, a value above one speeds it up, and any non-unit value causes the browser to resample the decoded buffer. That is precisely why raising pitch also shortens the audio and lowering pitch lengthens it. The new pitch and the new duration are two faces of the same resampling operation.
A +12 semitone offset yields a playback rate of 2^(12/12) = 2.0, doubling the pitch and halving the duration. A -12 offset yields 2^(-12/12) = 0.5, halving the pitch and doubling the duration. The perfect fifth, which sits seven semitones above unison, gives 2^(7/12), roughly 1.498, fast and bright. The perfect fourth, at five semitones, gives 2^(5/12), roughly 1.335. These are the standard equal-tempered intervals used throughout the rest of the article and are independent of sample rate, channel count, or codec.
Shift One Audio File with Audio Pitch Changer
The interface exposes only the controls needed for this resampling path, so the procedure is short and the result is predictable. Three actions produce a complete WAV: pick a file, pick a semitone integer, render and download. The detailed steps below mirror the operating contract exactly.
- Choose one browser-decodable audio file no larger than 50 MiB. Common MP3, WAV, M4A, AAC, Ogg, WebM, and FLAC extensions are accepted by the input control, but actual decoding still depends on what the current browser can decode, so a recognized extension is not a hard guarantee of success.
- Set a whole-number pitch shift from -12 through +12 semitones. A value of 0 keeps the original pitch, though the re-encoded PCM16 WAV can still differ from the decoded floating-point source because float-to-PCM16 conversion is itself a quantization step. +12 raises the material by one octave; -12 lowers it by one octave. Intermediate values produce the equal-tempered ratios discussed in the section above.
- Create the complete local render, review the stated duration change, and download the PCM16 WAV. The tool renders the full file through an OfflineAudioContext at the decoded sample rate, encodes every channel as interleaved little-endian PCM16 in a RIFF/WAVE container, clips floating-point samples to the legal -1 through +1 interval, and delivers the bytes as a single download. There is no silent tail cut and no hidden duration cap inside the WAV itself.
For a single worked example, take a 180-second clip rendered at +12 semitones. The formula gives 2^(12/12) = 2.0× playback, so the output frame count is the ceiling of 180 / 2.0 = 90 seconds of audio at the source sample rate. The downloaded WAV carries 90 seconds of audio at the same sample rate, but every frame has been resampled upward to match the doubled pitch. The full arithmetic is one substitution: rate = 2.0, duration_out = 180 / 2.0 = 90. That is the kind of result a user can predict on paper before clicking render.
Supported Inputs and the WAV You Download
The input side accepts one encoded file at a time, with a hard 50 MiB ceiling on the encoded payload. The browser then decodes the file into an AudioBuffer, which is what feeds the offline render. The decoded buffer is checked against several explicit budgets before any expensive output work begins, and any failure short-circuits with an error message rather than producing a partial download.
| Stage | Limit | Why it matters |
|---|---|---|
| Encoded input file | Up to 50 MiB | Larger payloads are rejected before decoding. |
| Decoded duration | Up to 5 minutes | Longer decoded audio is rejected. |
| Decoded channels | Up to 8 | More than eight decoded channels is rejected. |
| Decoded sample rate | 8,000 Hz to 192,000 Hz | Rates outside this band are rejected. |
| Decoded channel-samples | Up to 30,000,000 | Inputs above this are rejected before render. |
| Output channel-samples | Up to 30,000,000 | If a downward shift pushes the output over this budget, nothing is written. |
The downloadable WAV is always a fresh encode. It is uncompressed, interleaved, little-endian PCM16 inside a RIFF/WAVE container. Original compression quality, bitrate, ID3 or Vorbis tags, embedded artwork, chapter markers, cue points, loop metadata, and other container metadata are not carried into the export. The 16-bit quantization can differ from the decoded source's floating-point resolution, and the browser's resampler is implementation-defined, so a strong upward shift can reveal aliasing that was masked in the source. For transparent mastering, those caveats are decisive; for quick creative experiments, practice tracks, sound effects, and rough edits, the output is usually more than adequate.
Limits That Decide Whether the Render Completes
The output budget is the limit most often hit by users who assume "lower pitch" is always cheap. Lowering pitch lengthens the audio, so the number of output frames grows even as the input stays within budget. The product contract makes this explicit: an input that passes the decoded limit can still fail the output limit if the requested downward shift makes the required output exceed 30,000,000 channel samples. In that case the message says the requested shift is over budget and nothing is truncated; no partial WAV is offered.
Other guardrails are quieter but real. Every new input or new semitone value invalidates the previous render before another job starts, so an in-flight offline render cannot overwrite newer state. Decode contexts are closed, offline sources are stopped or disconnected when work is invalidated, and download Object URLs are revoked when they are replaced or when the page unmounts. Empty files, unsupported types, invalid decoded dimensions, and failed decodes are rejected with explicit messages rather than being silently converted. None of this affects a normal single-file use, but it explains why a large file with a deep downward shift may fail in a way a smaller upward shift would not.
When Pitch and Duration Must Stay Separate
There is one honest boundary this article must draw: the keyword promises quality without explaining what quality can mean. If by quality the reader means the output is a clean PCM16 file with no metadata loss, no extra compression pass, and no upload, this tool meets that bar. If by quality the reader means preserve the original tempo and duration while pitch changes, no playback-rate tool can meet that bar, and this one does not claim to.
| Property | Playback-rate resampling (this tool) | Time-stretching (separate workflow) |
|---|---|---|
| What changes | Pitch and duration together | Pitch and duration separately |
| Algorithm family | Sample-rate resample of a single buffer | Phase vocoder, granular, or similar analysis-resynthesis |
| Typical quality risk | Strong upward shifts can expose aliasing | Transient smearing and phase artifacts on percussive material |
| Right for | Practice tracks, sound effects, quick experiments | Production audio where tempo must stay locked |
| Browsers alone | Yes | Requires a dedicated library or external tool |
If a deliverable requires fixed length, use a phase vocoder or another time-stretching workflow in a DAW instead of a browser resampler. The MDN entry on playbackRate confirms that the Web Audio API exposes only the speed-changing resampler in standard form; independent time-stretching is not part of the same pipeline. The same point is worth noting for users who only need a small tempo tweak: a dedicated Audio Speed Changer covers the speed-only case without changing pitch, and the dedicated Audio Pitch Changer covers the pitch-shifting case here without claiming to preserve tempo.
What "Quality" Actually Means Here
Read against the keyword, the cleanest reading is "no upload, no second lossy encode, no silent truncation, and a format that is safe to re-edit downstream." Those four promises hold. The browser is the only environment that touches the audio. The offline render produces the full output frame count and only delivers the WAV if the channel count, sample rate, and frame count all match expectations. The PCM16 encoding is uncompressed and well supported in every editor that accepts WAV. The float-to-PCM16 conversion is itself a lossy step, so sample values do not always match the decoded source bit for bit.
Where the keyword overpromises is in any reading that treats quality as a synonym for musical transparency. Resampling, whether in a browser or in a desktop DAW, leaves a fingerprint. Strong upward shifts reveal aliasing. Strong downward shifts lengthen the file and push against the output budget. Container metadata does not survive the re-encode. The product contract describes the output as useful for quick creative experiments, practice tracks, sound effects, and rough editing, not as a transparent mastering process. Knowing which side of that line the project sits on is what makes the choice of tool correct.
For a deeper look, see How to Change Audio Speed on iPhone and Save the File.