How to find the bpm of any song — free, no upload
- Step 1Open BPM Finder and drop your song in — Drag an audio file onto the drop zone, or click to browse. MP3, WAV, FLAC, M4A, OGG, Opus, and video files are all accepted. There is nothing to configure — the tool has no options.
- Step 2Let the browser decode it —
decodeAudioDatadecodes the file to PCM locally. If your browser can play the format it can analyse it; the audio is never uploaded. - Step 3Detection runs automatically — The audio is downmixed to mono, downsampled to 11.025 kHz, broken into 10 ms energy windows, and the onset signal is autocorrelated across the 60-180 BPM range — on the GPU via WebGPU if available, otherwise on the CPU.
- Step 4Read the detected BPM and confidence — The top tempo and a 0-1 confidence score appear in the JSON report. High confidence means the top tempo clearly beat the runner-up.
- Step 5Check the five candidates for half/double-time — If the number looks off, scan the
candidateslist — the true tempo is almost always there as a 2x or 0.5x relative of the top result. Pick the one that fits the genre. - Step 6Copy or download the report — Use Copy to grab the JSON, or Download to save it as
<name>-bpm.jsonfor your cue sheet, set list, or sample library notes.
What actually runs in the browser
BPM Finder does NOT use FFmpeg. The whole pipeline is Web Audio decode plus a numeric onset-autocorrelation pass — that is why the result is a JSON report, not a re-encoded audio file. WebGPU is tried first for the autocorrelation loop; if WebGPU is unavailable the identical math runs on the CPU.
| Stage | What happens | Why |
|---|---|---|
| Decode | AudioContext.decodeAudioData decodes the file to PCM in the browser | Reuses the browser's own codec — MP3/WAV/M4A/OGG everywhere; FLAC/Opus depend on the browser |
| Downmix | All channels are averaged to mono | Tempo lives in the rhythm, not the stereo image — mono halves the work |
| Downsample | Resampled to 11.025 kHz via an OfflineAudioContext | A kick drum sits below 200 Hz, so high frequencies are irrelevant and dropping them bounds CPU cost regardless of source quality |
| Energy + onset | Energy is summed per 10 ms window; the onset signal is the positive frame-to-frame energy increase (an HFC-lite novelty function) | Beats show up as sudden energy jumps — this isolates them |
| Autocorrelation | The onset signal is autocorrelated across lags equivalent to 60-180 BPM; the top 5 scoring lags are converted to BPM | A repeating beat produces a periodic onset signal; the strongest correlation lag is the tempo period |
| Confidence | confidence = 1 - (second-best score / best score), rounded to 2 decimals | A clear winner over the runner-up means high confidence; two near-tied candidates means low confidence |
Fields in the JSON report
BPM Finder writes a small JSON object. It is shown in a scrollable panel with Copy and Download buttons; Download saves it as <name>-bpm.json. There are no options to set — the tool needs no configuration.
| Field | Type | Meaning |
|---|---|---|
bpm | number | The top-scoring tempo, rounded to one decimal (e.g. 128, 92.5) |
confidence | number 0-1 | How far the top candidate beat the runner-up; 1 - second/best, 2 decimals |
candidates | array of 5 | The five highest-scoring tempos, each { bpm, score }. score is the raw autocorrelation sum (unitless — only useful for comparing candidates within one run) |
gpuAccelerated | boolean | true when the autocorrelation ran on the GPU via WebGPU; false when it fell back to the CPU. The result is identical either way |
Tier limits for BPM detection
BPM Finder is a free-tier tool and the analysis never re-encodes audio. The limits below are the audio-family per-file caps from the JAD tier table — note durationMin is a per-file length cap, separate from file size.
| Tier | Max file size | Max duration / file | Files per batch |
|---|---|---|---|
| Free | 50 MB | 30 min | 1 file |
| Pro | 200 MB | 120 min | 10 files |
| Pro-media | 100 GB | unlimited | 100 files |
| Developer | 100 GB | unlimited | unlimited |
Cookbook
Real readings for the kind of finished tracks a DJ or editor drops in. The JSON shown is the actual report shape (numbers illustrative).
A clean four-on-the-floor house track
A steady 124 BPM house record is the easy case: every kick is a clean onset, the autocorrelation peak is sharp, and the runner-up is far behind — so confidence is high.
Input: deep_house_loop.mp3 (3:58)
Report:
{
"bpm": 124,
"confidence": 0.71,
"candidates": [
{ "bpm": 124, "score": 9182.4 },
{ "bpm": 62, "score": 5310.2 },
{ "bpm": 93, "score": 2104.9 }
],
"gpuAccelerated": true
}
bpm 124 with the half-time 62 trailing — solid reading.Hip-hop track that reads at half-time
A 140 BPM trap beat with a sparse kick can correlate more strongly at 70 (the backbeat). The expected tempo is still in the candidate list as the double-time relative.
Input: trap_beat.wav
Report (excerpt):
{
"bpm": 70,
"confidence": 0.18,
"candidates": [
{ "bpm": 70, "score": 6620.1 },
{ "bpm": 140, "score": 6011.7 },
...
]
}
Low confidence + two near-tied candidates = half/double tie.
The 'real' 140 is right there — pick it for a trap set.Verifying against a known metronome
Drop a bare 100 BPM click track to sanity-check the tool. A metronome is the cleanest possible onset signal, so confidence runs high and the value lands exactly.
Input: metronome_100bpm.wav
Report:
{
"bpm": 100,
"confidence": 0.88,
"candidates": [{ "bpm": 100, "score": 14002.0 }, ...],
"gpuAccelerated": false
}
gpuAccelerated:false just means this machine has no WebGPU;
the answer is identical to the GPU path.From BPM to a re-timed track
Once you have the tempo, push the track to a target BPM. Convert the percentage difference and feed it to the tempo-changer (pitch preserved).
Detected: 124 BPM, want 128 BPM for the next track in the set 128 / 124 = 1.032 -> +3.2% tempo Next step: tempo-changer at 103% (musicians' percentage), or time-stretcher at factor 1.032 to keep pitch unchanged.
A format the browser refuses to decode
An old Safari build won't decode FLAC. The fix is a one-step conversion before analysis.
Input: master.flac on Safari 14 -> decodeAudioData throws (no FLAC support) Fix: 1. flac-to-mp3 (or convert to WAV) 2. drop the .mp3 into BPM Finder Chrome and Safari 17+ decode FLAC natively — no step needed.
Edge cases and what actually happens
Tempo sits outside the 60-180 BPM search window
Octave-foldedThe autocorrelation only searches lags equivalent to 60-180 BPM. A 50 BPM ballad or a 190 BPM drum-and-bass track can't land outside that window, so the reported value is the half- or double-time fold that falls inside it (a 190 BPM track reads ~95). Inspect the candidates list — the true tempo is usually present as a halved or doubled relative of the top result.
Half-time / double-time ambiguity on a steady track
By designAutocorrelation cannot distinguish a backbeat from the main pulse: 140 and 70 are mathematically both valid periods of the same beat grid. The detector picks the strongest correlation, which is sometimes the half or double. Both values appear in candidates; pick the one that matches the genre you expect.
Speech, podcast, or ambient audio with no beat
UnreliableThe algorithm needs a periodic onset pattern. Dialogue, field recordings, and pad-only ambient have no repeating energy spikes, so the autocorrelation finds no clear peak — confidence collapses toward 0 and the bpm is effectively noise. For voice work you want the silence-stripper or speech-leveler, not a tempo reading.
Rubato, live, or tempo-drifting performance
Dominant tempo onlyOrchestral rallentando, a live band speeding up, or free-time jazz have no single tempo. The detector returns the dominant period across the whole file and silently misses the drift. Trim to one steady section with the audio-trimmer and re-run if you need a per-section reading.
Browser can't decode the format (FLAC/Opus on older Safari)
Decode errorDecode uses the browser's own decodeAudioData. Safari historically refused FLAC and pre-17 Safari refused Opus. If decode throws, the analysis can't start. Convert to WAV or MP3 first with wav-to-mp3 or flac-to-mp3, then run BPM Finder on the result.
Free-tier file is over 50 MB or 30 minutes
LimitFree tier caps each file at 50 MB and 30 minutes of duration — the duration cap is separate from size, so a long low-bitrate MP3 can hit it under the byte limit. Pro raises this to 200 MB / 120 min, Pro-media to 100 GB / unlimited. A single 3-4 minute song is never near the free cap.
Very short clip (a loop of a few seconds)
Low confidenceAutocorrelation needs enough repetitions of the beat to build a strong peak. A 2-3 second loop may produce a reasonable bpm but a thin confidence. Feed at least one full musical phrase (8-16 bars) for a stable reading.
Click track or metronome
SupportedA bare metronome is the ideal input — each click is a clean onset, the autocorrelation peak is sharp, and confidence runs high. This is a good way to sanity-check the tool against a known tempo.
Polyrhythmic or layered-tempo material
Dominant layer winsIf two rhythmic layers run at related tempos, the autocorrelation reports whichever produces the stronger periodic onset energy. Competing candidates show up in the candidates array with close scores and a low confidence — that closeness is your signal that the track is ambiguous.
Frequently asked questions
Does my audio get uploaded?
No. Decoding and the autocorrelation pass both run in your browser tab — the file's bytes never leave your device. Unlike many online BPM sites, there is no server round-trip, so there is nothing to upload and nothing to delete afterward.
Does this use FFmpeg like the other JAD audio tools?
No — and this is a common misconception. The converters and editors use FFmpeg compiled to WebAssembly, but BPM Finder is pure Web Audio: decodeAudioData plus a numeric onset-autocorrelation pass. That is why it outputs a JSON report instead of re-encoded audio, and why the metrics badge shows only GPU (when WebGPU ran), never the MT/SIMD flags the FFmpeg tools show.
What does the confidence number mean?
Confidence is 1 - (second-best candidate score / best candidate score). A value near 1 means the top tempo dominated every rival; a value near 0 means two or more tempos scored almost the same (usually a half/double-time tie). It is a relative separation measure, not a probability — treat anything under ~0.2 as 'verify by ear'.
Why are there five candidates instead of one answer?
The detector keeps the top five autocorrelation peaks so you can resolve the half-time / double-time ambiguity yourself. The true tempo is almost always either the top result or a 2x / 0.5x relative of it sitting lower in the list. The score field lets you see how close the runners-up were.
What's the supported BPM range?
The autocorrelation searches lags equivalent to 60-180 BPM. Tempos outside that window get folded into it: a 50 BPM track reads near 100, a 190 BPM track reads near 95. That covers the vast majority of pop, rock, electronic, and hip-hop. For extreme tempos, read the value as a half/double of the candidate that matches your genre.
What file formats can I analyse?
Whatever your browser can decode: MP3, WAV, FLAC, M4A, OGG, Opus, and the audio track inside common video files. Decoding relies on the browser's built-in codecs, so FLAC and Opus support depends on the browser (Chrome and recent Safari handle both; very old Safari does not). If a format won't decode, convert it to WAV or MP3 first.
How fast is it?
A 3-4 minute song typically resolves in under two seconds on a modern laptop. The pipeline downmixes to mono and downsamples to 11.025 kHz before any heavy math, so analysis time barely changes whether the source is a 128 kbps MP3 or a 24-bit/96 kHz WAV.
Does WebGPU change the answer?
No. WebGPU only moves the autocorrelation loop onto the graphics card for speed; the math is bit-for-bit the same as the CPU path. The gpuAccelerated flag in the report (and the GPU badge in the UI) just tells you which path ran. On machines without WebGPU it silently uses the CPU and you get the identical BPM.
Can I change the analysis settings?
No — BPM Finder has no options. The window size, downsample rate, and search range are fixed for reliable, repeatable results, so there are no sliders or presets to get wrong. You drop a file and read the report.
It reported half (or double) the tempo I expected — is it broken?
No, that's the half-time / double-time ambiguity inherent to autocorrelation: a beat at 140 BPM is also perfectly periodic at 70 BPM. Look at the candidates array — the value you expected is almost certainly listed there as a 2x or 0.5x of the reported bpm. Pick the one that fits the genre.
Can I re-time a track once I know its BPM?
Yes. Take the detected BPM, then use the tempo-changer to nudge the track to a target tempo (expressed as a percentage), or the time-stretcher to stretch by a factor without shifting pitch. To see the rhythm you measured, render it with the waveform-generator.
Do I need an account?
No. BPM Finder is a free-tier tool with no sign-in required. Signing in only raises the file-size and duration caps (Pro and above) and records a private processed-file counter for dashboard stats — never the audio itself.
How accurate is it for a typical song?
For 4/4 music with a clear kick — house, pop, rock, hip-hop — it's reliably within about ±1 BPM, and the confidence score will be high. The main thing to watch is the half-time / double-time fold, which the five candidates let you catch and correct. For a paid DJ set, always confirm the chosen value by ear.
Can I find the BPM of a song from a YouTube or streaming source?
Only if you have the audio as a local file (you can extract it from a video file with a tool like video-to-mp3). BPM Finder analyses files on your device — it has no way to pull audio from a streaming URL, and respecting those services' terms is on you.
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.