Skip to content

What Is an M4B File? The Audiobook Format, Taken Apart

Updated August 10, 2026 • 13 min read

Something arrived on your Mac with .m4b on the end of it, and nothing you own seems eager to open it. Or Books opened it and quietly filed it next to your music.

Short answer: it is an audiobook file. Under the hood it is an ordinary MP4 with a different label — which is why some apps shelve it with music and others refuse it.

Came here to make one rather than define one? AudioBo does the whole job in one pass — chapters, tags, cover, the audiobook flag. The rest of the page takes the format apart.

That label turns out to be most of the story, and the rest of this page is what sits under it: what the file is made of, why chapters show up in one player and vanish in the next, and why macOS calls every M4B “protected” even when it plainly is not.

The short version

An M4B is an audiobook file: ordinary audio, plus a label that tells a player it is a book. The sound inside is the same kind your music player already handles. What is added is a list of chapters, the title, author and cover, and one small flag that says to shelve this with books rather than with songs.

That flag is why an audiobook remembers where you stopped and lands on the audiobook shelf instead of in the music library. It is also why renaming a music file so it ends in .m4b changes nothing: the label lives inside the file, not in its name.

Nothing in an M4B is a program — it is sound and a table of contents. And if all you want is to listen, there is nothing to convert: Apple Books opens one directly, and so does VLC.

Need to make one, rather than take one apart? AudioBo does the whole checklist in one pass: chapters written in both of the forms players look for, so they show up whichever app you open the book in, the title, author and cover filled in, and the flag that keeps the file out of your music library. It will also fix the metadata and cover on a book you already have without re-encoding the audio.

It builds and repairs the file. It cannot make a player show something that player does not support — the per-chapter covers further down this page are the example — and it does not remove DRM from a book you bought from a store.

The same answer, in the format’s own terms

An .m4b file is AAC audio inside an MPEG-4 container, with three things a music file does not carry: chapter markers, book metadata, and a flag that tells players to shelve it under books rather than songs.

There is nothing executable in it. It is audio data and a table of contents.

What opens it, before anything else

If all you want is to listen, you do not need a converter and you do not need this page’s second half.

Apple Books on macOS and iOS opens .m4b directly — drag it into the Books window and it lands in Audiobooks. VLC plays them. So do Plex, Audiobookshelf, and a long list of third-party players; the compatibility grid on the AudioBo page is the longer version. If Books misbehaves when you drop the file in, that is a known and fairly predictable set of causes, covered in adding M4B audiobooks to Apple Books on Mac.

Everything below is for when you want to know why the format behaves the way it does.

What is actually inside one

An M4B is stored in two pieces: one long block of sound, and a small index that describes it. The index is where the chapter list, the title, the author and the cover all live. The sound is very nearly the entire file and the index costs almost nothing, which is why changing a book’s title or its cover does not mean rebuilding the audio.

The other thing to know before the details: the chapter list is written down twice, in two different places, and that is deliberate.

I built a small M4B for this page — thirty seconds of tone, three chapters, nothing else — and walked its atom tree. This is the whole file:

ftyp (28)              — file type declaration: M4B
free (8)
mdat (241210)          — the audio data
moov (6632)            — the index
  mvhd                 — duration, timescale
  trak (5741)          — audio track
    tkhd
    tref
      chap             — "my chapters live in that other track"
    mdia
      hdlr             — SoundHandler
      minf/stbl        — sample table
  trak (531)           — chapter text track
    mdia
      hdlr             — SubtitleHandler
      minf/stbl
  udta
    meta/ilst          — title, author, cover, media type
    chpl (79)          — the chapter list again, second format

Three things worth noticing.

ftyp comes first, and it is tiny. Twenty-eight bytes at the very start of the file declare the brand: the literal ASCII M4B — four characters, trailing space included. exiftool spells that brand out as “Apple iTunes AAC-LC (.M4B) Audio Book”. It is a declaration, not a dependency: I overwrote those four bytes with garbage, and ffmpeg still decoded the whole file and still listed all three chapters, because the demuxer works from moov. What broke was identification — exiftool stopped calling the file an M4B and called it a plain MP4.

mdat is the audio and it is nearly the entire file. In my test, 241 KB of a 248 KB file. All the structure — chapters, tags, cover — costs almost nothing. That is why editing an M4B’s metadata does not have to re-encode anything.

The chapters appear twice. Once as a separate track, once as an atom in udta. That is not a bug, and it is the single most useful thing to understand about this format.

Want to see this on something that is not a synthetic test file? AudioBo’s page publishes the atom tree and the raw ftyp hex for a real six-hour book.

Is M4B lossless? No

No. The audio inside an M4B has been squeezed to make the file small, and what was thrown away in the squeezing is gone for good. Converting the file again does not bring any of it back; it squeezes what is left a second time.

Which matters in one practical way only: if the book you have sounds fine, leave it alone. Converting it again for tidiness can only subtract.

The technical word for that squeezing is lossy — and this one gets answered wrong constantly, so plainly: the audio inside an M4B is lossy.

It is AAC — usually AAC-LC — which is the same class of thing as MP3, better at the same bitrate. Encoding to it discards information. AudioBo’s own FAQ says this without hedging: MP3 sources get re-encoded to AAC, “also lossy”, with the practical note that files already in AAC with suitable parameters can be copied rather than re-encoded, at zero additional loss.

The container is a separate question from the codec, and the pedantic answer is that MPEG-4 can carry Apple Lossless. Want to try it yourself? I did: ffmpeg -i in.m4a -c:a alac out.m4b produces a valid file, and ffprobe reads it back as “ALAC (Apple Lossless Audio Codec)”. So a lossless .m4b is constructible.

You will not encounter one. Audiobooks are speech, speech compresses extremely well, and nobody ships a 40 GB narration.

The practical consequence: if a file already sounds fine, running it through another lossy encode only subtracts. Re-encoding is something to do when you need to, not as housekeeping.

Chapters are stored two different ways, which is why they vanish

A book that shows a tidy chapter list in one app and one unbroken six-hour block in another is not damaged, and there is nothing in it to fix. The chapter list is in the file. The two apps are looking in different places for it.

That happens because there are two different spots inside an audiobook where a chapter list can be kept, and no rule saying which of them a player has to read. A book with its list in both spots works everywhere. A book with its list in only one works in half the apps you own and looks empty in the rest.

Here is the differentiating detail of the whole format.

An M4B can hold its chapter list in two places, and most well-built files hold it in both:

  1. A QuickTime chapter track. A second, tiny track in the file containing the chapter titles as text, with the audio track carrying a tref/chap reference pointing at it. In my test file this shows up in ffprobe as a second stream: codec_type=data, codec_tag_string=text, handler SubtitleHandler.
  2. The Nero chpl atom. A flat list of timestamps and titles sitting in udta, next to the metadata.

In my three-chapter test file, the string “Chapter One” appears twice in the raw bytes — once per storage method. The full cost of carrying both, measured against the same file built without chapters: about 700 bytes — 531 for the chapter text track, 79 for chpl, 20 for the tref/chap reference, and 77 for the titles themselves inside mdat.

Players do not agree on which one to read, and nothing in the format obliges them to agree.

Want to watch two tools disagree? ffmpeg takes the chapter track: I rewrote the titles in chpl alone, and ffprobe went on reporting the originals. So a file can show a clean chapter list in one app and one undifferentiated six-hour blob in another, with no corruption anywhere and nothing to “repair” — the file has chapters, your player is looking in the other drawer.

This is also why “the chapters disappeared after I converted it” is such a common complaint: plenty of tools write one format and drop the other. If that is your situation, M4B with no chapters is the page for it.

AudioBo writes both formats on export, which is the boring correct answer to a problem that has no elegant one.

M4B vs M4A: two declarations and about 700 bytes apart

The thing almost everyone tries first is renaming: change the last letter of the file name and hope the Mac starts treating a music file as a book. It does not work, and it is worth knowing exactly why.

Renaming changes the name. It does not touch anything inside the file, and everything that makes a book a book is inside the file — the label saying “book”, and the chapter list. A rename adds neither, so no player is fooled.

M4A and M4B are the same container with the same codec. What separates them is two declarations and one small body of data.

Check it yourself: I copied an .m4a to .m4b and hashed both files.

a810b5e5c9c31239488700704fc374a2  a.m4a
a810b5e5c9c31239488700704fc374a2  renamed.m4b

Byte-for-byte identical, which is exactly what you would expect — renaming touches the filename, not the file. Inside, exiftool still reports the brand as “Apple iTunes AAC-LC (.M4A) Audio”, there is no chapter track, no chpl, and no media-type flag.

A real M4B differs in two declarations:

  • the ftyp brand is M4B instead of M4A
  • the iTunes stik atom is set to the audiobook value — AtomicParsley reads it back as Atom "stik" contains: Audiobook

It also carries what the renamed file has no trace of: the chapter text track, the tref/chap reference, the chpl atom, and the titles in mdat. That part is data, not declaration — the 700 bytes from the section above.

Those two flags are what earn you resume-where-you-left-off and a place in the book library instead of the music library; the chapter data is what fills in the navigation. A renamed file gets none of it, which is the actual reason behind “I renamed it and it still shows up as music”.

Which means everything M4B buys you is behavioral, not audible. The samples are the same samples. Whether that behavior is worth rebuilding an existing MP3 library over is a separate and genuinely open question — M4B vs MP3 for audiobooks works through the cases where it pays off and the ones where it does not.

Worth saying: ffmpeg will not save you from this by accident. Encoding straight to a .m4b filename produces a file whose header still says M4A — I checked, and the first sixteen bytes are identical to the .m4a version. You have to ask for the brand explicitly with -brand "M4B ". That is not ffmpeg being wrong; it is ffmpeg doing precisely what you told it and nothing more, which is the whole personality of the tool.

What macOS thinks an .m4b is, which is odd

If you ever go poking at what your Mac says about one of these files, you will find the word “protected” attached to it — to every M4B on every Mac, including one you made yourself thirty seconds ago with nothing protecting it at all. macOS decides that from the file extension and nothing else. It is a naming quirk, not a statement about your file, and it has sent a lot of people looking for a problem they do not have.

Want to see it on your own Mac? Run mdls on an M4B you built yourself, with no protection of any kind in it, on macOS 26.6:

kMDItemContentType = "com.apple.protected-mpeg-4-audio-b"
kMDItemContentTypeTree = (
    "public.item",
    "com.apple.protected-mpeg-4-audio",
    "public.data",
    "com.apple.protected-mpeg-4-audio-b",
    ...
)

The same file, renamed to .m4a, types as com.apple.m4a-audio with public.mpeg-4-audio in its tree. No “protected” anywhere.

So macOS assigns the type from the extension alone, and the type it assigns to every .m4b in existence has “protected” in its name. Your unprotected file inherits the label anyway. It is cosmetic, it confuses people who go looking, and it explains a certain amount of forum panic.

DRM, in one paragraph

If a file refuses to play anywhere except one company’s app, that is DRM rather than a fault, and it is the one problem on this page that nothing here can do anything about. A .m4b bought from a store can carry DRM. One you build yourself does not — mine has no protection in it and never did. Nothing on this site removes it: AudioBo does not strip DRM and will not. The canonical version of this discussion lives on converting M4B to MP3 on a Mac, where it matters most.

Building an M4B: the checklist, and what AudioBo does with it

Reading an M4B is easy. Building one that behaves correctly is fiddly — not hard in any single step, just a long list of small things that all have to be right at the same time. Miss one and the file plays perfectly while behaving wrong: the chapters are not there, or the cover never appears, or the book sits in the music library. That is the most annoying failure mode there is, because nothing looks broken.

AudioBo is the version of that checklist you do not have to remember. What comes out is a finished audiobook: chapters written in both of the forms players read, so they show up whichever app you open the book in, the title, author and cover in place, and a file that lands on the book shelf rather than in with your songs. If the problem is a book you already have rather than one you are making, it edits the metadata and the cover without touching the audio at all — nothing is re-encoded, so nothing is degraded. It also exports to M4A or MP3 when you need something that plays on a car stereo with opinions.

That is the whole of it. If you would rather not read another word about atoms and brands, you have everything you need.

If you do want the mechanical version: producing a correct M4B is a pile of small obligations — a single unbroken timeline, AAC at a sane bitrate, chapters written in both formats, stik set, ftyp branded, cover embedded, tags filled in. ffmpeg will do every step of that. It will also require you to know each step exists and to specify it, and the chapter-format question alone is a research afternoon. AudioBo writes chapters in both QuickTime and Nero formats so they show up reliably across players, and edits metadata and cover art in place without re-encoding the audio. Version 1.3.4 added per-chapter cover images, with an honest caveat printed in its own release notes: the covers are always written into the file, but not every player draws them, and Apple Books on Mac is one of the players that shows only the book cover.

If you are starting from a folder of MP3s rather than an existing M4B, converting MP3 to M4B on a Mac is the workflow end to end. If you have an M4B and the metadata is the problem, editing M4B metadata, cover, and chapters covers the repair path, and splitting an M4B into chapter files covers the case where one file is the problem.

What it cannot do, and it is the boundary of the whole app: AudioBo builds and repairs the file, and that is all it does. It cannot make a player show something that player does not support — those per-chapter covers are the example, correct in the file and still not drawn by Apple Books on Mac — and it does not strip DRM from a store download, as the section above says.

That cover caveat is the format in miniature. The file can carry more than any single app chooses to show you — which is worth knowing before you conclude something is broken.

Common questions

Is an M4B file safe to open?

Yes. An M4B is a media file — audio data plus metadata, with nothing executable in it. The one real caution is the same as for any download: know where it came from. If the file plays in VLC or Apple Books and shows a sensible duration, it is what it claims to be. A file that refuses to play at all is more likely broken or store-protected than dangerous.

Is M4B lossless?

No, not in normal use. The audio inside an M4B is almost always AAC, which is a lossy codec — the same family as MP3, more efficient at the same bitrate. The MPEG-4 container itself can technically carry Apple Lossless, and ffmpeg will happily mux ALAC into a .m4b, but no audiobook you download will be built that way.

What is the difference between M4A and M4B?

The container and the codec are identical. What differs is the four-character brand written into the file's ftyp atom and the media-type flag inside it: M4B declares itself an audiobook, M4A declares itself audio. That is what makes players offer resume, chapter navigation, and a shelf in the book library rather than the music library.

Can I rename an M4A to M4B?

You can, and the file bytes will be completely unchanged — I copied an .m4a to .m4b and both files had the identical MD5. Inside, it still declares the M4A brand and still carries no chapters. macOS will change how it types the file, but any player that reads the header sees an audio file with a misleading extension.

Why does my M4B have no chapters?

Either they were never written, or they were written in only one of the two formats M4B files use — a QuickTime text track, and the Nero chpl atom — and your player reads the other one. A file can look chaptered in VLC and completely flat in Apple Books for exactly that reason.