Encode a document
Paste a JSON object and the BSON bytes appear as hex or Base64. Every document starts with its own total length as a little-endian int32 and ends with a null byte, which is why the smallest possible document is 5 bytes.
{"hello": "world"} becomes 16000000026865..., 22 bytes against 18 for the JSON text.
BSON is usually larger
This is the format that often loses the size comparison, and the structure explains it. Each element stores a type byte, the field name as a null-terminated string, and for strings a 4-byte length plus a terminator. Nested documents and arrays repeat their own length prefix.
The tradeoff is deliberate. Those length prefixes let a server skip a subdocument without parsing it, which matters when the reader is a database scanning millions of records rather than a client decoding one payload.
Arrays cost more than they look
An array is written as a document whose keys are the stringified indexes. A 100-element array carries the field names 0 through 99 in the bytes, so the first 10 items cost 2 bytes of key each and the rest cost 3. Long arrays of small numbers are where the gap against MessagePack and CBOR opens widest.