Chapterization
An M4B audiobook is a standard MP4 container with one extra feature: a chapter table embedded alongside the audio stream. That table is just a list of timestamps and titles: "Chapter 1" starts at 0:00, "Chapter 2" starts at 14:32, and so on. Before converting, M4BConvert reads that table accurately and lets you edit it, so cuts and rebuilds follow exactly what you set.
Reading existing chapters
M4B files in the wild store chapter data in two different ways depending on
what tool created them: an older chpl atom format, or a newer
QuickTime-style chapter track. Generic metadata libraries typically support
only one of the two, which is why some tools silently show "0 chapters" on a
perfectly valid audiobook. M4BConvert sidesteps that problem by asking ffmpeg
itself to dump the file's metadata in its ffmetadata text format,
which understands both variants because it goes through the same parsing code
ffmpeg uses for every other operation:
That text is parsed into a simple list of { startMs, endMs, title }
objects. A few edge cases are handled deliberately: the TIMEBASE
ratio can vary between files, titles can contain literal =
characters, and the final chapter's END value is sometimes
missing entirely, in which case it's inferred from the start of the next
chapter (or the file's total duration, if it's the last one).
If a file genuinely has no chapter table at all (a plain MP3 audiobook, for instance), M4BConvert doesn't error out. It falls back to treating the entire file as a single chapter, so the rest of the pipeline (preview, export, rename) still works the same way.
Editing chapters
Once chapters are loaded, you can rename them, retime them, delete them, or add
new ones before converting. Timestamps accept several formats:
1:23:45, 83:45, or a plain number of seconds like
5025.3, and these are normalised to milliseconds internally so that
splitting stays frame-accurate regardless of how you typed it.
Writing chapters back
When merging individual MP3 or M4A files into a single M4B, the process runs in reverse: each input file becomes one chapter, its title taken from the filename (or a name you set), and its boundaries calculated from the running total of the files that came before it. ffmpeg then writes a fresh chapter table into the resulting M4B alongside the merged audio.
The ffmpeg.wasm engine
Audio conversion is genuinely hard to get right (codecs, container formats, bitstream quirks between encoders) which is why M4BConvert doesn't reimplement any of it. It loads ffmpeg.wasm, a build of the real ffmpeg project compiled to WebAssembly, and runs the exact same encoding logic that ships in ffmpeg's command-line tool, just inside the browser's sandbox instead of on a server.
WebAssembly (WASM) is a binary instruction format that runs at near-native speed in any modern browser. Loading ffmpeg this way means the multi-megabyte core library and its compiled audio codecs are fetched once, cached by the browser, and then executed locally for every conversion, with no round trip to a server required for the actual encoding work.
Single-threaded vs. multi-threaded
ffmpeg.wasm ships two cores: a single-threaded one that works everywhere, and a
multi-threaded one that's significantly faster but requires the page to be
running in a cross-origin isolated context (a browser security
mode needed to safely use SharedArrayBuffer). M4BConvert registers a
service worker at load time specifically to enable this isolation without
requiring special server configuration, and automatically falls back to the
single-threaded core if isolation can't be established; conversions still
work either way, just at different speeds.
Web Workers keep the page responsive
Encoding runs inside a dedicated Web Worker, a background thread separate from the one rendering the page. That's why the progress bar keeps animating, the tab doesn't freeze, and, combined with the Wake Lock API, the conversion keeps running even if the screen would otherwise dim or the tab is in the background.
Local processing
Every step described above (reading chapters, decoding audio, re-encoding, writing the output file) happens on your device. There is no upload step anywhere in the flow, because there's no server-side component to upload to.
This is also why M4BConvert has no per-file size limit, no daily quota, and no watermarking. Those restrictions exist on server-based converters because someone else's compute and bandwidth is paying for every file. Here, the only constraint is your own device's memory and CPU, which is the next thing this page covers.
Where temporary data actually lives
Two browser storage mechanisms come up while a conversion is in progress, and it's worth being precise about both since "your browser" can mean different things:
- MEMFS (in-memory filesystem): ffmpeg.wasm's default mode. The file is loaded into a virtual filesystem that lives entirely in the page's RAM allocation for the duration of the conversion, and is freed when the job finishes or the tab closes.
- OPFS (Origin Private File System): a sandboxed area of your actual disk that only this site's pages can read or write, not your regular Downloads folder, and not visible to other websites. M4BConvert uses it for large files (see Low-RAM mode below) and clears its cache automatically once a job completes or fails.
Turbo & Low-RAM modes
Splitting a long audiobook into dozens of chapters is, by nature, dozens of independent encoding jobs. M4BConvert can run those jobs two different ways depending on the size of the file and the memory available on your device.
Turbo (parallel)
Loads up to four ffmpeg engine instances at once and processes that many chapters simultaneously. Fastest option, but each instance holds its own copy of the working data, so memory use scales with how many you run.
Low-RAM (streaming)
Uses a single engine, processes chapters one at a time, and streams the source file from OPFS instead of copying it into a JavaScript buffer first , which is roughly half the peak memory of normal mode, at the cost of speed.
By default, M4BConvert checks the file size against a threshold calculated from
your device's reported memory (via navigator.deviceMemory where
available, with a conservative fallback where it isn't) and switches to Low-RAM
mode automatically if a file is large enough that Turbo mode would risk
crashing the tab. You can always override the suggested mode manually.
Supported formats
| From | To | What happens |
|---|---|---|
| M4B | MP3 | Each chapter is split out and encoded to standard 128kbps or VBR ~190kbps MP3. |
| M4B | M4A | Chapters are split using a lossless stream copy, so quality is identical to the source. |
| MP3 | M4B | Multiple MP3 files are merged in order into one M4B, with each input becoming a chapter. |
| M4A | M4B | Multiple M4A files are merged the same way into a chaptered M4B audiobook. |
.mp4 files are also accepted as input wherever .m4b is.
Some apps export audiobooks with an .mp4 extension even though the
container and codec are identical, so they're routed to the same converters.
Frequently asked questions
Does my file get uploaded anywhere?
No. The conversion runs inside the ffmpeg.wasm engine described above, entirely within your browser tab. See the Local processing section for the technical detail.
Why does it say "single-threaded" sometimes?
Multi-threaded WebAssembly requires cross-origin isolation, which depends on browser support and, occasionally, a hard refresh to activate the service worker that enables it. Conversions still complete in single-threaded mode, just more slowly.
Is there a file size limit?
There's no limit enforced by the converter itself. In practice, very large files (multi-gigabyte audiobooks) are best handled in Low-RAM mode, since browsers impose their own per-tab memory ceilings regardless of what M4BConvert does.
Why didn't my M4B's chapters show up?
This usually means the file was created without a chapter table at all (some podcast-to-audiobook conversions skip it). M4BConvert will fall back to treating the file as one single chapter, which you can still split manually using the timestamp editor.
What happens to OPFS-cached data after I close the tab?
The cache is cleared automatically once a job finishes, errors out, or you start a new file. It's also scoped entirely to this site's origin, so no other website can read it, and it isn't part of your regular file system.