How is a MongoDB ObjectID 12 bytes? - mongodb

Question

From what I know, Strings in MongoDB are stored in UTF-8, so each character is between 1 and 4 bytes.
MongoDB documentation says the following about ObjectID:
Returns a new ObjectId value. The 12-byte ObjectId value consists of:
a 4-byte value representing the seconds since the Unix epoch,
a 5-byte random value, and
a 3-byte counter, starting with a random value.
In an example, it shows ObjectId("507f1f77bcf86cd799439011"). This String is 24 bytes though in UTF-8, so I don't understand where the 12 bytes come into play.

Answer 1

As per the ObjectId documentation, that string you see is a hex representation of the 12 bytes. It's not Unicode or even a string. It's actually a number.
A byte is 8 bits, meaning that it can have 2^8 == 256 possible values (see Byte).
How do you represent a number with 256 possible values succinctly? How about representing it as 16^2 instead? You can achieve this by using 2 hexadecimal values (base 16). The only thing you need to invent is a numbering system that goes to 16 instead of 10.
As a matter of fact, we use letters from a to f to represent values 10 to 15.
Thus, one byte can be represented in two hexadecimal numbers. It just happens to use a to f since we couldn't be bothered to invent special symbols for them. They are not letters. They are numbers.
So no, the string you see in ObjectId does not represent 24 bytes. Every 2 characters represent a byte instead. 24 hex numbers == 12 bytes.

Answer 2

Supplementing the #kevinadi answer , let's examine a bit the code of ArrayBuffer presented below for 12 bytes of ObjectId reflected representation where as every indexed character (elements, characters – both are synonyms in this particular context) within our chosen TypedArray is in the condition of "2 BYTES_PER_ELEMENT". As far as I am considered MongoDB 12 bytes ObjectId + 4 unused indexed allocations within fixed-size TypedArray composes 16 byte (hexadecimal approach) , where as if not compressed , this would be equivalent of 24 elements + 8 unused indexed allocations (in total 32). In every part of scenario 2 times 16 (MongoDB ObjectId is presented in hexadecimal string) is equal to 32 . Simple math , right ? Now let's examine a bit the possible interpretation of ArrayBuffer in use with TypedArray chosen to mock the process of allocation vs. compression and their properties of: .length vs. .byteLength respectively :
const init_buffer = new ArrayBuffer(16); // init allocation
const uint8_inst1 = new Uint8Array(init_buffer);
const uint8_inst2 = new Uint16Array(uint8_inst1);
console.log("2 BYTES_PER_ELEMENT i.e. 2 times less than total quantity of characters available [compressed approach]: ", uint8_inst2.length);
console.log("How many characters in total available [uncompressed approach]: ", uint8_inst2.byteLength);