How to convert ogg audio to mp3 locally — no server required
- Step 1Open the tool (no install) — Load the page. The engine strip shows WASM SIMD, multi-thread availability and your core count — this is FFmpeg running locally, not a remote service.
- Step 2Drop the OGG file — Drag the
.oggin. It is read into the tab; nothing is uploaded. The dropzone also accepts WAV, FLAC, M4A, Opus and video, so it covers most local conversion needs. - Step 3Confirm the stream details — The panel reads the Vorbis header and shows sample rate and channels. The converter preserves these — equivalent to running FFmpeg without
-ar/-acoverrides. - Step 4Set the bitrate (= -b:a) — The Bitrate dropdown maps to FFmpeg's
-b:a: 320k, 256k, 192k (default), 128k, 64k. Pick the same value you would pass on the command line. - Step 5Run locally — Click Run OGG → MP3. FFmpeg-WASM executes in the tab on your CPU. If your browser is cross-origin isolated, multi-threaded FFmpeg (MT) uses several cores; otherwise it runs single-threaded but produces identical output.
- Step 6Download — or automate with the runner — Download the MP3, or for repeatable batches pair the desktop runner and POST the job (slug +
bitrateoption) to the local endpoint. Either way, conversion stays on your machine.
Browser tool vs. the FFmpeg command line
How each control and behaviour maps to the equivalent ffmpeg CLI flag.
| This tool | FFmpeg CLI equivalent | Notes |
|---|---|---|
| Drop OGG + Run | ffmpeg -i in.ogg out.mp3 | Same demux + decode + encode pipeline |
| Encoder (fixed) | -c:a libmp3lame | MP3 output always uses LAME |
| Bitrate dropdown | -b:a 192k (etc.) | Enum: 64k / 128k / 192k / 256k / 320k in the UI |
| Sample rate (preserved) | no -ar flag | Source rate kept; use the sample-rate-converter to change it |
| Channels (preserved) | no -ac flag | Source layout kept |
| Tags carried over | -map_metadata 0 | Vorbis comments copied to ID3v2.3 |
| Cover art carried over | -map 0:v? -c:v copy -disposition:v:0 attached_pic | Re-attached as MP3 APIC; no-op if none |
| ID3 version | -id3v2_version 3 | Written for broad player compatibility |
Local processing options
Three ways to run the same local conversion, depending on how repeatable you need it.
| Method | Install needed | Best for |
|---|---|---|
| Browser tab (this page) | None | One-off conversions, locked-down machines |
| Desktop runner + local API | Runner once | Scripted / repeatable batches, larger files |
| Native ffmpeg CLI | ffmpeg | When you already have it and want a shell pipeline |
Cookbook
Local OGG-to-MP3 jobs with the matching ffmpeg command for reference. Every one runs without uploading.
Single file, default bitrate
The everyday case. The tool's defaults match a plain CLI invocation with an explicit 192k bitrate.
Tool: drop in.ogg, Bitrate = 192k, Run
CLI : ffmpeg -i in.ogg -c:a libmp3lame -b:a 192k \
-map_metadata 0 -id3v2_version 3 out.mp3
Both: 192 kbps MP3, source sample rate + channels kept.Highest quality (320k)
Music you want as a high-quality MP3. Set the bitrate to 320k.
Tool: Bitrate = 320k CLI : ffmpeg -i in.ogg -c:a libmp3lame -b:a 320k out.mp3 Output: 320 kbps MP3
On a Chromebook / locked-down laptop
No package manager, no admin rights, no ffmpeg. The browser tab is the whole toolchain — nothing to install.
Problem: can't run `apt install ffmpeg` (no admin) Solution: open this page, drop the .ogg, Run -> FFmpeg-WASM does the encode in the tab, locally
Repeatable batch via the desktop runner
For a recurring job, pair the runner and POST to the local endpoint. Files are processed on your machine; nothing is uploaded.
POST 127.0.0.1:<port>/v1/tools/ogg-to-mp3/run
{ "options": { "bitrate": "192k" }, "files": [ ... ] }
Runs ogg-to-mp3 locally via the paired runner.
Option schema: single `bitrate` (enum 64k–320k).Change sample rate? Use a different tool
This converter does not resample (no -ar). If you need 48 kHz output from a 44.1 kHz source, chain the sample-rate-converter.
Need: 44.1 kHz OGG -> 48 kHz MP3 This tool: keeps 44.1 kHz (no -ar) Do instead: sample-rate-converter (set 48 kHz) -> then this tool /audio-tools/sample-rate-converter
Edge cases and what actually happens
Same codec path as the CLI
By designMP3 output always uses libmp3lame, the same encoder ffmpeg -c:a libmp3lame invokes. The browser build is FFmpeg 8.1 compiled to WebAssembly, so the decode/encode chain is the CLI's, just running in the tab on your CPU.
No resampling unless you chain another tool
By designThis tool preserves the source sample rate (no -ar). If you need a different output rate, run the sample-rate-converter first. Keeping the source rate is the safe default and matches CLI behaviour without -ar.
Single-thread when not cross-origin isolated
Slower, identical outputMulti-threaded FFmpeg needs SharedArrayBuffer (cross-origin isolation). On a browser without it, the engine strip shows single-thread (ST); conversion still completes with byte-identical output, just using one core. Long files take proportionally longer.
Works fully offline
By designAfter the page loads, no network is needed — FFmpeg-WASM is in the tab. You can convert with Wi-Fi off. This is also why there is no server round-trip and nothing is uploaded, which matters on confidential data.
File is OGG Opus, not Vorbis
SupportedFFmpeg decodes Opus as well as Vorbis, so an OGG-Opus file converts to MP3 here too — just like the CLI would. For Opus voice notes there is also a dedicated Opus to MP3 tool.
Large file beyond browser comfort
Use the runnerVery large files are bounded by browser memory. For multi-hundred-MB or multi-hour jobs, use the desktop runner, which processes locally on your machine without the tab's memory ceiling. Free's 50 MB cap keeps the in-tab path comfortable.
Bitrate set above the source
ExpectedEncoding a low-bitrate Vorbis source at 320k just makes a larger file without recovering quality — same as on the CLI. Pick a bitrate at or near the source for an efficient result.
Corrupt OGG fails to demux
errorIf the Ogg container is truncated or the Vorbis stream is damaged, FFmpeg may error out — the same Invalid data found when processing input you would see on the CLI. Re-acquire the source file; a partial OGG sometimes decodes up to the damage.
Frequently asked questions
Is this really running FFmpeg locally?
Yes — it is FFmpeg 8.1 compiled to WebAssembly, running in your browser tab on your CPU. The engine strip shows WASM SIMD, multi-threading and core count. There is no server doing the conversion; the file is never uploaded.
How does it compare to `ffmpeg -i in.ogg out.mp3`?
Same pipeline: it demuxes Ogg, decodes Vorbis, and encodes MP3 with libmp3lame, writing an ID3v2.3 tag and preserving source sample rate and channels. The Bitrate dropdown maps to -b:a. The main difference is there is nothing to install.
Do I need to install FFmpeg or anything else?
No. That is the point — the WebAssembly build runs in the browser, so it works on a Chromebook, a locked-down work laptop, or any machine where you cannot or do not want to install ffmpeg. For scripted batches, the optional desktop runner is the only install.
Does it resample like passing -ar?
No — by default it preserves the source sample rate, the same as running ffmpeg without -ar. If you need a specific output rate, run the sample-rate-converter first, then convert to MP3.
What encoder does it use?
MP3 output always uses libmp3lame (the LAME encoder), the same one the FFmpeg CLI uses for high-quality MP3. There is no alternative MP3 encoder option; bitrate is the control you adjust.
Can I automate or script it?
Yes — pair the desktop runner and POST jobs to its local endpoint with the slug ogg-to-mp3 and a single bitrate option (enum 64k–320k). It processes files locally on your machine, so an automated pipeline still uploads nothing.
Does it work offline?
Yes. Once the page has loaded, no network is required — FFmpeg-WASM is already in the tab. You can disable Wi-Fi and still convert, which doubles as proof that nothing is being uploaded.
Is it slower than native ffmpeg?
Somewhat — WebAssembly has overhead versus a native binary, and single-thread mode (when the browser is not cross-origin isolated) is slower still. For typical songs and episodes the difference is seconds. For heavy batches, the desktop runner or native ffmpeg will be faster.
Will it keep my Vorbis comments / tags?
Yes — equivalent to -map_metadata 0, it copies title/artist/album/year, and re-attaches embedded cover art as an MP3 APIC frame. If the OGG had no tags, nothing is copied; add them with the id3-editor.
Can it handle OGG Opus files too?
Yes — FFmpeg decodes Opus as well as Vorbis, so OGG-Opus converts to MP3 here just as it would on the CLI. The dedicated Opus to MP3 tool adds voice-friendly defaults if you are converting voice notes.
What's the largest file I can convert in the browser?
Free caps at 50 MB / 30 minutes, Pro at 200 MB / 120 minutes. Beyond that, browser memory becomes the practical limit, so use the desktop runner (Pro+Media: 100 GB / unlimited) for very large or very long files. The runner also processes locally.
Is the output identical regardless of how many cores it uses?
Yes. Whether FFmpeg runs multi-threaded (cross-origin isolated) or single-threaded, the encoded MP3 is the same — threading only affects speed, not the bytes produced at a given bitrate.
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.