BSON supports binary data for values that are not naturally represented as text or ordinary numeric fields. Binary data is represented using the BSON binary type and can carry a subtype describing its intended representation.

Examples of binary data include:

• UUID values.
• Encoded application payloads.
• Certain cryptographic or protocol-specific values.
• Data that a supported application workflow explicitly stores in binary form.

UUIDs

A UUID is a 128-bit identifier commonly used across distributed systems. MongoDB supports UUID values through BSON binary representations.

UUID representation matters because historical drivers and applications may use different UUID byte-order conventions or representations. When exchanging UUID values between services, configure compatible representations and test round trips.

In modern Node.js applications using the MongoDB driver, follow the driver's documented UUID representation behavior rather than assuming that every string or binary UUID has identical storage semantics.

String identifiers versus binary UUIDs

A UUID can be represented as a textual string such as:

550e8400-e29b-41d4-a716-446655440000

It can also be represented using a BSON binary UUID representation. These are different storage representations, even though they may encode the same logical identifier.

If your _id values are stored as strings, query them as strings. If they are stored as UUID-compatible BSON binary values, use the appropriate UUID representation supported by the driver.

Storing files

Small binary values may be stored directly in a BSON document when appropriate, but the 16 MiB document size limit applies.

For large files, consider object storage or MongoDB's GridFS mechanism, depending on the requirements. GridFS stores file data in chunks across collections rather than placing an entire large file into one BSON document.

The best storage choice depends on access patterns, file sizes, retention, consistency requirements, and operational complexity.