How to bpm detector — no upload, nothing leaves your device
- Step 1Drop the file — it stays local — Drag your audio onto the drop zone. The bytes never leave your device; there is no upload step and no options to set.
- Step 2Browser-local decode —
decodeAudioDatadecodes the file to PCM in your tab using the browser's built-in codecs. No server, no native binary. - Step 3Onset signal is built on-device — The PCM is downmixed to mono and downsampled to 11.025 kHz, then reduced to a compact 10 ms onset signal — a numeric beat map, not the audio.
- Step 4Autocorrelation runs on your hardware — The onset signal is autocorrelated across the 60-180 BPM range on the GPU (WebGPU) or CPU. The audio itself is never transmitted.
- Step 5Read the tempo and confidence — The JSON report shows the top BPM, a confidence score, and five candidates for resolving half/double-time.
- Step 6Copy or download — no trace left — Save the report as
<name>-bpm.json. Close the tab and nothing about your audio remains anywhere off your machine.
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
Examples framed around private, no-upload workflows. JSON shows the real report shape (numbers illustrative).
Checking an unreleased master without exposing it
An unreleased single needs its BPM filed in the metadata sheet. The master never leaves the studio machine.
Input: UNRELEASED_single_master_v3.wav
Report:
{ "bpm": 116, "confidence": 0.69,
"candidates": [{ "bpm": 116, ... }, { "bpm": 58, ... }],
"gpuAccelerated": true }
No upload occurred. The .wav is untouched on disk.Proving no network call carried the audio
For an NDA-sensitive file, you can verify the no-upload claim yourself in DevTools.
DevTools > Network, drop client_master.flac: no POST of audio bytes no fetch to an analysis API The page is WASM-free for this tool; analysis is local JS.
Batch of demos, one at a time, all local
Free tier handles one file per run; drop each demo in turn. None are uploaded; nothing is cached server-side.
demo_01.mp3 -> { bpm: 128, confidence: 0.62 }
demo_02.mp3 -> { bpm: 92, confidence: 0.55 }
demo_03.mp3 -> { bpm: 174, confidence: 0.21 } (DnB: see 87 in candidates)
Pro tier allows up to 10 files per batch if you sign in.Read-only: the master is never altered
Because it's analysis, not conversion, there's no risk of an accidental re-encode degrading your master.
Before: master.wav (24-bit / 96 kHz, 412 MB)
After: master.wav (24-bit / 96 kHz, 412 MB) — identical
+ master-bpm.json (analysis only)
Note: 412 MB needs Pro-media (free caps at 50 MB).Format your master can't decode in-browser
If the browser can't decode the container, convert a copy first — the original stays private and intact.
Input: master.flac on old Safari -> decode throws
Fix: flac-to-mp3 on a copy, then BPM Finder
(or wav-to-mp3 if you exported a WAV)
The original FLAC is never modified or uploaded.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 can I be sure nothing is uploaded?
Open your browser's DevTools Network panel and drop a file — you'll see no request carrying the audio bytes and no call to an analysis endpoint. Decoding uses the browser's own decodeAudioData and the analysis is local JavaScript/WebGPU. The only server interaction is loading the static page itself.
Is a copy of my file kept anywhere after I close the tab?
No. The file is held in memory only while the tab is processing it and is discarded when you close or reload. BPM Finder is read-only — it doesn't re-encode, cache, or persist your audio, and for signed-in users it records only a count of files processed (never the content).
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.