About

MongoDB stores binary data using the BinData BSON type. When a .NET or Java application writes a GUID into MongoDB, the driver may apply byte reordering to the first three sections of the UUID - a legacy behavior known as CSUUID (subtype 3). Querying that document directly with the original GUID string returns nothing. The bytes for Data1 (4 bytes), Data2 (2 bytes), and Data3 (2 bytes) are stored in reversed (little-endian) order, while Data4 (8 bytes) remains unchanged. Getting this wrong means your db.collection.find() queries silently return empty result sets with no error - a debugging trap that wastes hours.

This tool performs the exact byte-swap logic offline in your browser. It handles both subtype 3 (legacy CSUUID with byte reordering) and subtype 4 (standard UUID, no reordering). It also reverses the operation: paste a BinData value and recover the original GUID. No data leaves your machine. Note: this tool assumes the legacy C# driver byte order. If your driver uses the standard UUID representation, select subtype 4.

Formulas

A GUID consists of 16 bytes (128 bits) represented as 32 hexadecimal characters. The canonical format is:

Data1−Data2−Data3−Data4a−Data4b

For subtype 3 (legacy CSUUID), the byte-swap function S operates on the hex string:

S(hex) = rev₄(Data1) + rev₂(Data2) + rev₂(Data3) + Data4

Where rev_n reverses n bytes (each byte = 2 hex chars). For example, rev₄(3F2504E0) takes pairs [3F, 25, 04, E0] and produces [E0, 04, 25, 3F] → E004253F.

The swapped 16-byte sequence is then encoded to Base64:

BinData(3, base64(S(guid)))

For subtype 4 (standard), no byte swap is applied:

BinData(4, base64(guid))

Where guid is the raw 32-character hex string (hyphens stripped), base64 converts each pair of hex chars to a byte and encodes the resulting 16-byte buffer to a Base64 string of length 24 (with 2 padding chars).

Reference Data

GUID Section	Byte Length	Hex Chars	Subtype 3 Behavior	Subtype 4 Behavior	Example (Input)	Example (Subtype 3 Output)
Data1	4 bytes	8	Bytes reversed	No change	3F2504E0	E004253F
Data2	2 bytes	4	Bytes reversed	No change	4F89	894F
Data3	2 bytes	4	Bytes reversed	No change	11D3	D311
Data4	8 bytes	16	No change	No change	9A0C0305E82C3301	9A0C0305E82C3301
MongoDB BinData Subtypes Reference
Subtype 0	Generic binary		Raw bytes, no UUID semantics
Subtype 1	Function		Deprecated BSON function type
Subtype 2	Old binary		Deprecated; includes length prefix inside data
Subtype 3	UUID (Legacy)		Driver-dependent byte order (CSUUID, JavaUUID, PyUUID)
Subtype 4	UUID (Standard)		RFC 4122 byte order, no swapping, cross-driver compatible
Subtype 5	MD5		16-byte MD5 hash digest
Subtype 6	Encrypted		Client-Side Field Level Encryption payload
Subtype 7	Column		Queryable Encryption v2 (MongoDB 7.0+)
Subtype 128-255	User-defined		Application-specific binary data

Frequently Asked Questions

If the GUID was inserted by the legacy C# MongoDB driver, it was stored as BinData subtype 3 with byte-swapped Data1, Data2, and Data3 groups. Querying with the original GUID hex string does not match the stored bytes. You must apply the same byte-swap transformation and query using BinData(3, "") to get a match.

Subtype 3 is the legacy UUID representation where each language driver applied its own byte ordering - the C# driver reverses bytes in Data1 (4 bytes), Data2 (2 bytes), and Data3 (2 bytes). Subtype 4 follows RFC 4122 strictly: no byte reordering, all drivers produce identical output. MongoDB 4.0+ recommends subtype 4 for cross-driver compatibility.

Yes. Copy the generated BinData(...) string and paste it directly into mongosh or the legacy mongo shell. For example: db.users.find({ _id: BinData(3, "4AQlP4lJ0xGaDAN+giwzAQ==") }). Ensure you match the correct subtype number to how the data was originally written.

No. The Java legacy driver applies a different byte reorder pattern for subtype 3. This tool implements the C# (CSUUID) byte order only. Java's legacy UUID (JUUID) swaps bytes differently across all groups. If you need Java-compatible conversion, ensure you are not using this C#-specific logic. Subtype 4 avoids this issue entirely by using a universal byte order.

Switch this tool to "BinData → GUID" mode. Paste the Base64 payload and select the matching subtype. The tool decodes the Base64 to 16 bytes, applies the reverse byte swap for subtype 3 (or no swap for subtype 4), and reconstructs the canonical GUID format with hyphens: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx.

No. A GUID is exactly 128 bits. Base64-encoding 16 bytes always produces a 24-character string (including 2 padding "=" characters). The transformation is lossless and perfectly reversible. The only source of error is selecting the wrong subtype for your driver.